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ABSTRACT 


Recently, Decision Support Systems (DSS) have increased in 
importance and usage. However, these increases have not 
carried over into developing better models to estimate the 
real cost of developing the DSS. This thesis explores various 
estimation methods that seem pertinent to DSS. It advocates 
the use of a combination of modeling tools particularly 
tailored to the users' environment. An Intelligent Cost 
Estimation Model (ICEM) for Decision Support System software 
is proposed. To promote user-friendliness, ICEM uses a rule- 
based front-end interface coupled to a spreadsheet program. 
For comparison purposes the current version of ICEM includes 
the Intermediate COCOMO model, the Intermediate COCOMO model 
particularly calibrated for the in-house DSS development 
environment, and a parametric model which incorporates the 
function point size metric. 
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THESIS DISCLAIMER 


The reader is cautioned that computer programs developed ,■ 

in this research may not have been exercised for all cases of 
interest. While every effort has been made, within the time 
available, to ensure that the programs are free of computa¬ 
tional and logic errors, they cannot be considered validated. 

Any application of these programs without additional verifica¬ 
tion is at the risk of the user. Additionally, the ICEM 
program is available from the thesis advisor, however, since 
VP-Expert and VP-Planner Plus are a copyright of Paperback 
Software International, they can not be included for 
distribution. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Recently, Decision Support Systems (DSS) have increased in 
importance and usage. Likewise, there has been an increase in 
literature regarding the design and development of DSS 
software. Unfortunately, these increases have not carried 
over into developing better models to estimate the real cost 
of developing the DSS. Current literature argues that a DSS 
should be developed quickly and inexpensively; however, user 
requirements in terms of interface and modeling capabilities 
often significantly increase development cost [Ref. 1]. 

As the cost of software projects has soared over the past 
decade there have been several attempts to develop cost 
estimation models that would allow a manager to accurately 
predict the development cost of software projects. Some of 
these models are addressed in Chapter IV. With cost and 
demand for new software at an all-time high and increasing 
backlogs of undeveloped software projects, the development of 
better cost estimation models is more important today than it 
ever has been. 

B. SCOPE 

The purpose of this thesis is to explore the possibility 
of combining the advantages of parametric and heuristic 
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modeling to better estimate the development cost of DSS 
software. 

The main thrust of this study will be in the design and 
implementation of an Intelligent Cost Estimation Model (ICEM) 
that would allow a DSS builder to predict and. refine 
development cost. Due to the considerable difficulty of DSS 
software estimation, this work will focus on small scale DSS 
applications developed by small programming groups whose 
development tools consist of high level programming languages. 
Furthermore, it will concentrate on developing a calibrated 
model for the DSS environment based on the COCOMO and function 
point concepts. 

C. METHODOLOGY 

When estimating the cost of software development the 
quality of the estimation depends upon the precision of the 
software specification. By their nature, Decision Support 
Systems deal with ill-defined problems. This, in turn, makes 
it difficult tc accurately estimate the cost of developing the 
DSS. Two research methodologies can be applied in developing 
cost estimation models. These include the parametric and 
heuristic approaches. This research attempts to combine these 
two approaches to gain some insights on the DSS cost behavior. 
An integrated design approach will be used to implement the 
model. It will consist of a rule-based expert system which is 
coupled to a spreadsheet model. The expert system is used to 
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gather heuristic information for cost estimation, while the 
spreadsheet provides the framework for the parametric model 
which performs statistical calculations. 

D. ORGANIZATION 

This thesis is broken down into nine chapters with two 
appendices. After the introduction in Chapter I, the thesis 
begins in Chapter II by first looking at the framework in 
which cost estimation models are classified. The issue of 
size metrics and how they effect the development of cost 
estimation models are addressed in Chapter III. Different 
methods used in measuring software size are also addressed in 
this chapter along with the advantages and disadvantages of 
each metric. Chapter IV presents an overall review of several 
cost estimation models currently available. The COCOMO and 
Function Point models are studied in greater detail in 
Chapters V and VI respectively. The ICEM model is presented 
in Chapter VII. Chapter VIII provides an empirical analysis 
of the ICEM model based on collected data. Due to the 
inaccurate nature of some required information, calibration 
was performed only for the COCOMO model. Chapter IX contains 
the conclusion and future recommendations. A sample session 
with the ICEM model showing screen formats is provided in 
Appendix A. Finally, the source code for the ICEM model is 
provided in Appendix B. 
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II. A FRAMEWORK TO CLASSIFY COST ESTIMATION MODELS 

There have been many models developed to estimate the cost 
of software development. Most of these models are empirical 
models that use information gathered from previous projects to 
make future predictions of current projects such as time, 
effort, and cost requirements. They derive basic equations 
from past projects using statistical tools such as linear 
regression. Models tyrically utilize one or a combination of 
five major parameters for estimation: productivity, schedule, 
cost, quality, and size. The most common parameter used for 
estimation is size (see Chapter III). 

Models have been classified under many different formats. 
Many models are defined as being either micro or uiacro models. 
A micro model derives effort estimations from small pieces of 
information which have been scaled upwards (bottom-up 
approach) . The total effort is derived from the sum of all of 
the smaller effort estimates. On the other hard, a macro 
model is based upon a view of the big picture (top-down 
approach) . Effort is estimated for the entire product 
development and then proportioned between the separate 
development activities. 
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A. BASILI'S CLASSIFICATION SCHEME 


One of the disadvantages in using the micro/macro scheme 
for classifying models is that it is very limited in scope; it 
only separates models into two large groups. A more detailed 
schemie was developed by Victor Basili, who distinguished 
models according to the type of formula thev used to calculate 
total effort [Ref. 2]. He defined models as being single¬ 
variable if only one basic variable was used as a predictor of 
effort and multi-variable if several were used. He further 
defined models as being either static single-variable, static 
multivariable, or dynamic multivariable. 

1. Static Single-variable Model 

In a static sing]e-variable model, a unigue variable 
such as SLOC (Source Lines of Code) is utilized in the derived 
eguations to make predictions about other variables such as 
cost or time. The basic effort eguation of this model takes 
on the following form: 


Effort = a*Size’^' 

where a and b are estimated constants derived through linear 
regression of a historical database. The Walston-Felix and 
the basic COCOMO cost estimation models are examples of 
single-variable models. A description of all cost estimation 
models referred to in this chapter may be found in Chapter IV 
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with the exception of the COCOMO and Function Point models 
which are described in Chapters V and VI respectively. 

2. S tatic Multivariable Models 

Cost estimating models, as defined by Basili, may also 
be categorized as static multivariable. A model is considered 
multivariable if it is based on several parameters and static 
if a single effort value is calculated by the model formula. 
The static multivariable models use the additional parameters 
to make adjustments to the original estimation. These 
adjustments are most often based on historical data. This 
model is further subcategorized as being either an adjusted 
baseline model, an adjusted table-driven model, or a multi¬ 
parameter equation model. 

a. Adjusted Baseline Model 

The adjusted baseline model uses a single-variable 
baseline equation which is adjusted in some way by a set of 
other variables. The Intermediate COCOMO model fits this 
category as its baseline effort estimate relies only upon 
project size and it applies a set of adjustment multipliers to 
its effort equation. 

b. Adjusted Table-Driven Model 

The adjusted table-driven model uses a baseline 
estimate adjusted by a set of variables whose relationships 
are defined in tables built from historical data. An example 
of this is the Wolverton model. This model contains a basic 
algorithm which involves categorizing the software routines. 
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c. Multi-parameter Model 

In the multi-parameter model, a base formula is 
used which contains several variables. The GRC model contains 
several multiparameter equations containing more than one 
variable. 

3. Dynamic Multivariable Model 

The final category defined by Basili is the dynamic 
multivariable model. Unlike the static model, the dynamic 
model does not have a single basic variable. Rather, it 
contains a set of inter-dependent variables which respond to 
changes over a period of time, such as staffing levels. The 
Putnam model is a dynamic multivariable model that assumes a 
specific distribution of effort over the life of a software 
development project. 

Figure 2.1 shows the model categories and their 
relationships as described by Basili. 

B. THIBODEAU'S CLASSIFICATION SCHEME 

Another categorization scheme for cost estimation models 
v/as developed by Robert Thibodeau. Thibodeau grouped models 
into three separate categories based on the method the model 
uses in making estimations. These include: regression, 

heauristic, and phenomenological. [Ref. 4] 

1. Regression Model 

In the regression model, parameters are developed for 
a single cost estimation equation by using linear regression 
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Figure 2.1 Model Relationships 
[Ref. 3;p. 32] 

on available data. This model is specific to the environment 
in which it is developed. Examples of regression models 
include the Doty, COCOMO, and GRC models. 

2. Heuristic Model 

Unlike the regression model, the heuristic model is 
considered to be free from any singular mathematical 
formulation. Heuristic models usually combine a number of 
different estimating techniques. They provide a flexible 
approach which utilizes observations of relations, interpreta¬ 
tions, and a certain amount of subjectivity. They provide an 
intuitive development of an estimate which takes advantage of 
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previous estimates and adjustment factors. Examples of 
heuristic models include the Boeing, Price S, and Wolverton 
models. 

3. Phenomenological Model 

The third type of model described by Thibodeau is the 
phenomenological model. This category was developed for and 
is based on the SLIM model. It is unique in the fact that it 
is the only model to use observed basic relationships which 
are unrelated to the software development process. These 
relationships are more representative of scientific law rather 
than adaptive interrelationships which are used in heuristic 
models. 

C. SUMMARY 

From all of the previous category listings it is evident 
that there are many methods for classifying cost estimation 
models. These methods are often useful when analyzing 
different cost estimation models. However, regardless of the 
classification of the model, almost all of the cost estimation 
models underestimate their values. Additionally, if the model 
is not properly calibrated to the user's environment, this 
estimation error may be as great as 500 percent or more [Refs. 
5-8]. With this in mind, it is the intent of this thesis to 
develop an integrated automated model (ICEM) which utilizes 
two of the best models currently available. The ICEM model 
will combine the benefits of a parametric model (COCOMO) with 
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the advantages of a heuristic model (Function Point) in order 
to provide a better cost estimating tool. By using models 
based on different classification schemes, the user will 
better be able to validate estimations. Additionally, this 
model will provide the user with two alternative methods for 
making cost estimations. This allows the user the ability to 
select the model most appropriate for the given situation. 
Since the ICEM model will be calibrated to the unique 
environment of Decision Support Systems, it is only 
recommended for this environment. 
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III. SIZE METRICS 


Almost all of the cost estimation models currently 
available use some form of size measurement or size metric for 
making productivity and effort estimates. Likewise, most of 
the error in estimating cost of software development is 
attributed to error in estimating the size of the program. An 
accurate and consistent method for obtaining size measurements 
is essential to the success of most cost estimation models. 
As DeMarco [Ref. 9:p. 3] states in reference to metrics, "You 
can't control what you can't measure." This is also true for 
estimation, you can't estimate without proper input 
measurements. 

A. SOURCE LINES OF CODE 

One of the most common methods for measuring the size of 
a project is by measuring the number of source lines of code 
(SLOC) which it contains. It would seem that measuring the 
number of lines of code would be an easy and accurate process 
for providing a consistent size measurement; however, in order 
to do this one must first determine what constitutes a line of 
code. This can vary depending on the desired output. For 
instance, when trying to determine the functional size of a 
program it is generally accepted that only executable 
statements are counted as lines of code; therefore, comments. 
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blank lines, and data are not considered. But, if determining 
the total amount of effort is the desired result then all 
factors should be included in the measurement. 

Furthermore, there still remains a problem that the effort 
required for writing a line of executable code may be easy or 
difficult depending on the task. Therefore the size of a 
program measured in SLOC does not provide a standard basis for 
determining the effort involved. For example, a 100-line 
program could take as little as a day to develop or as much as 
a week depending on the complexity of the program task. 

Another problem with using SLOC measurements is that 
programs are written in many different languages, such as 
Pascal, ADA, Fortran, Cobol, and Assembly language. The 
amount of code required to perform a task in one language does 
not necessarily equate to the number of lines that another 
programming language would require to perform the same task. 
Additionally, SLOC unfairly penalizes fourth generation 
languages for their additional complexity. This point is 
demonstrated in the empirical analysis of Chapter VIII. Since 
most DSS are developed using fourth generation languages this 
is very disadvantageous. 

B. FUNCTION COUNTS 

In order to overcome the problems associated with SLOC, 
there have been many other methods introduced for measuring 
program size. Function counts is one such method which 
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concentrates on measuring the amount of functions in a 

program. Conte et al. [Ref. 10:p. 43] defined a function: 

...as a collection of executable statements that performs a 
certain task, together with declarations of the formal 
parameters and local variables manipulated by those 
statements. 

The advantage in using the number of functions as a size 
metric is that essentially, the number of functions will 
remain the same regardless of the language the program is 
written in. Additionally, during early life cycle development 
when the code has not yet been developed, it is often easier 
to estimate the number of functions that will be required than 
to estimate the SLOC. The down side to this method is that 
there is considerable overhead and cost in counting the number 
of functions. This overhead discourages the definition of a 
small function. Theoretically, a function could be as small 
as a single statement or as large as an entire procedure 
depending on how it is defined. This could lead to 
consistency problems and as programs are separated into larger 
functions the benefits of this method are lost. 

C. HALSTEAD'S SOFTWARE SCIENCE 

As previously discussed, one of the major problems with 
SLOC is consistency, since some lines of code are more 
difficult to code than others. One solution to this problem 
is to give more weight to lines that are more complex. 
Maurice Halstead developed such a scheme in his metric called 
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Halstead's method uses 


Software Science [Ref. 11]* 
measurements of operators and operands. 

Operators are primarily symbols or keywords that specify 
an action. They consist of arithmetic symbols (such as +, 
and /) , command names (such as IF, IF..THEN..ELSE, or 
DO..WHILE), special symbols (such as :=, braces, and 
semicolons) , and finally grouping functions (such as 

BEGIN..END). Since BEGIN..END performs the same function it 
is considered one operator. Operands are the symbols used to 
represent data. They consist of variables, constants, and 
labels. 

Software Science uses measurements of operators and 
operands to make predictions about a program's length, volume, 
difficulty, level, and effort required. The length of a 
program is calculated as a dimensionless quantity but can be 
converted to SLOG by dividing by a constant which is language- 
dependent [Ref. 10:p.41]. The volume of a program is also a 
size measurement, but it is in terms of the minimum number of 
bits required for programming. Volume is dependent upon a 
measurement that is referred to as a program's vocabulary. 
The basic metrics of Software Science are defined as: 
n^ = number of distinct operators in a program 
n 2 = number of distinct operands in a program 
Ni = number of occurrences of operators in a program 
N 2 = number of occurrences of operands in a program 
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Estimations are accomplished by using the following 
equations: 

N = Observed Program Length = + N 2 

N = Estimated Program Length = n^ (log 2 (n,) ) + n 2 (log 2 (n 2 )) 
n = Program Vocabulary = n^ + n 2 

V = Program Volume = N(log 2 (n)) 

D = Program Difficulty = (ni/2) / (N 2 /n 2 ) 

L = Program Level = 1/D 

E = Effort = V/1 

It has not been sufficiently proven that the metrics 
proposed by Halstead are actually any better at estimating 
size than SLOG and there have been many people who have 
questioned its effectiveness [Fifs. 10; 12-15]. In view of 
this, and with the increased cost and overhead associated with 
the Halstead and other metrics, SLOG has continued to be the 
dominant size metric. Additional information regarding the 
Halstead and many other software metrics and models may be 
found in a comprehensive collection of related articles by 
Victor Basili [Ref. 16]. 

D. FUNGTION POINTS 

Probably one of the more successful and rapidly growing 
methods for measuring size has been Albrecht's Function Point 
Analysis method [Refs. 17; 18]. The function point metric was 
also developed as an alternative to LOG as the principle 
sizing metric. Function Point metrics do not measure LOG, 
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rather, they focus on program functionality. This is not to 
be confused with the function count method previously 
discussed. Function Point Analysis is not simply a 
measurement of the number of functions. Rather, it measures 
five specific areas which include: inputs, outputs, 
interfaces, files and inquiries. A complexity factor is used 
to adjust the numeric values of each of the five areas. These 
values are then summed to obtain a function point count which 
can be used as a dimensionless sizing metric or further 
equated to a SLOC measurement. 

Most of the cost estimation models that have been 
developed are unable to make accurate estimates early in the 
development phase of a project. This is because most of the 
models rely on SLOC as the primary size metric and estimating 
SLOC early in the life cycle is very difficult and highly 
inaccurate. Boehm [Ref. 19;p. 311] illustrated the difficulty 
cost models have in making accurate estimates early in the 
life cycle of a project. This is shown in Figure 3.1. 

The method of calculating function points is described in 
detail in Chapter VI. One of the advantages of using function 
points is that they can be computed early in the development 
cycle, essentially after the requirements and functional 
specifications are written. Additionally, by concentrating on 
program functionality the problems associated with using 
different languages disappear. However, some researchers also 
point out some non-negligible problems associated with this 
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Figure 3.1 Software Cost Estimation Accuracy 
Versus Phase [Ref. 19:p. 311] 


method. First, the counting of the function points is prone 
to subjective assessment. Second, it is difficult to collect 
measurements on a specific information domain after-the-fact. 
Finally, since the function point calculation is a 
dimensionless quantity, it might convey little meaning. [Ref. 
20:p. 94] 

E. OTHER PRODUCT ATTRIBUTES 

Although size estimates are very important in developing 
a cost estimation model there are several other major 


17 






attributes which are also utilized. Boehm [Ref. 21:p. 11] 
identified five major attributes used in cost estimation and 
the factors that measure them. Figure 3.2 displays these 
attributes and factors in relation to their use by the various 
models described in Chapter IV. 
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Figure 3.2 Factors Used in Various Cost Models 
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IV. EXISTING COST ESTIMATION MODELS 


A. BACKGROUND 

The following is a brief introduction of several models 
that have been developed for software cost estimation. In 
presenting these models it is important to note that the 
majority of the models have been developed based on a 
particular set of data and environmental factors. Therefore, 
most of the models are not transportable unless they provide 
a method for recalibration. Furthermore, a majority of the 
models require complex mathematical calculations that are very 
cumbersome for the user to apply to their own situations. 

There are a few models, however, that have been automated 
and are commercially available. These incJude the SLIM, PRICE 
S, ESTIMACS and SOFTCOST models. Bailey et al. [Ref. 22] 
provides a detailed evaluation of many of the automated 
software cost-estimation models currently available. 

Further detailed explanation of each model may be found in 
the original source reference listed for each model. An 
overview of a majority of the models is also provided by Boehm 
[Ref. 19:pp, 510-520], Londeix [Ref. 3:pp. 36-41] and 
Thibodeau [Ref. 4]. The COCOMO and Function Point models are 
described in detail in Chapters V and VI respectively and are 
not covered in this section. 
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B. COST ESTIMATION MODELS 

1. SDC Model 

The SDC model was developed from a study completed by 
the System Development Corporation (SDC) for the U.S. Air 
Force in the mid-1960's (Ref. 23]. This study included an 
extensive analysis of 104 attributes of 169 software projects. 
The SDC model proved to be highly inaccurate as a cost 
estimator. It raised serious doubts about the ability of a 
linear cost estimation model to estimate cost. However, it 
did provide valuable information and spurred new research into 
the area of cost estimation. 

2. TRW Wolverton Model 

The TRW Wolverton model is a matrix-based model which 
was developed for use at TRW [Ref. 24], In the model, 
estimates of routine size are converted to costs using cost 
per instruction values that are functions of the routine type 
and complexity. A matrix of ratios is used to allocate the 
total cost to seven phases with each phase divided into up to 
25 activities. 

The essence of the model can be seen in Figure 4.1, 
which is an example using the 6 categories of the model. The 
chart demonstrates how the cost per object instruction is 
related to the relative degree of difficulty. Relative degree 
of difficulty is determined by whether a routine is considered 
old or new and whether it is classified as easy, medium or 


hard. 








Relitiv* degrtf of dil'iculty ptrceni of iota, 
sample experiencing this rate O' le» 


Figure 4.1 TRW Wolverton Model: Cost 
Per Object Instruction Vs. 
Relative Degree of Difficulty 
[Ref. 19;p. 513] 


By multiplying the cost per instruction for each 
routine by its number of object instructions and summing the 
products for all of the routines, an estimated value for total 
development cost may be obtained. This cost is then allocated 
to each of the seven phases of development and their 
attributes as defined by the model. 
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It is important to note that the ratios developed in 
the TRW Wolverton model are only applicable for the TRW 
database. Therefore, new ratios and a new matrix would have 
to be developed if a different environment was to be used. 

3. Putnam (SLIM) Model 

The Software Life Cycle Model (SLIM) is a commercially 
available costing model developed by Quantitative Software 
Management, Inc. [Refs. 25; 26). It is primarily based on the 
estimating model developed by Larry Putnam in the late 1970s. 
The SLIM model depends on a SLOC estimate for the project's 
general size. It also uses formulas which relate software 
size to cost and schedule requirements. Therefore it is not 
exactly a pure form of the phenomenological model as described 
by Thibodeau [Ref. 4]. However, a major portion of the model 
is dependent upon relationships which follow the scientific 
Rayleigh distribution curve. In particular, the model relates 
the software life cycle to the Rayleigh curve. 

A majority of the articles regarding the Putnam model 
and how it incorporates the Rayleigh distribuLion curve may be 
found in [Ref. 27]. Weiner-Ehrlich et al. [Ref. 28] provides 
an additional source of information regarding the use of the 
Rayleigh curve for software modeling. 

The Slim model uses the following equation in 


developing its estimation model; 






S3 = c, X td 


'./s 


where; 

S 3 = source statements (code size in SLOC) 

Cj, = technology constant (dimensionless usually 10040) 

K = life cycle effort in man-years 
tj = development time in years. 

The SLIM model combines the estimation equation with 
Monte Carlo simulation, standard deviation analysis, and 
Rayleigh/Norden distribution curve analysis to provide a 
unique estimate of effort and development time. One of the 
basic assumptions of this model is that manpower utilization 
during program development follows the Rayleigh curve. 
Therefore, manpower and cash flow rate may be obtained at any 
point in the life cycle. 

SLIM provides two methods for properly calibrating the 
model: the user can calibrate the model by either inputting 

data from completed projects, or by answering a series of 22 
questions from which Slim will provide recommended calibration 
entries. 

4. Doty Model 

In 1977, Doty Associates Inc., produced a software 
cost estimation study of the software developed for the RADC 
(Rome Air Development Center) [Ref. 29]. The objective of the 
study was to reduce the variance between the estimated and 
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actual cost of software development. The study resulted in 
the development of the Doty model. 


The model is actually a set of individual models. 
Each one to be used for a given type of software environment. 
Equations have been developed empirically using regression 
analysis for four application areas which include: command 
and control, scientific, business and utility. These 
equations use size inputs to estimate the number of man-months 
of effort required for the program as defined by its category 
type. A general set of equations is also available for 
programs which do not fit into any of the four predefined 
categories. The model also uses a series of 14 effort 
multipliers in order to better refine the cost estimate to the 
development environment. The model is considered a static, 
multivariable model. 

5. RCA PRICE S Model 

The PRICE S model is an automated proprietary cost- 
estimation model developed and maintained by PRICE Systems 
Division of RCA, New Jersey [Ref. 30]. It is currently 
available through an On-line system which can be reached by 
modem over a standard telephone line. The model was primarily 
designed for aerospace applications. It is considered a macro 
estimation model as it uses a top-down approach throughout its 
estimation development. 

PRICE S uses inputs of size, type and difficulty and 
a series of hypothesized relationships in order to make 
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estimates of project cost and schedule. Most inputs are 

heuristic in nature as they are based on certain subjective 

opinions of the user, such as; 

the cost required to produce programs, 

the effect on cost of changing development time, 

the comparative costs of the development cycle 
elements. 

Since every project is different and will take in 
different inputs, the model does not have a standardized set 
of equations with predetermined coefficient values for 
calculating effort. 

6 . Walston and Felix IBM-FSD Model 

This model was developed by Walston and Felix at IBM 
Federal Systems Division in an attempt to measure the rate of 
production of lines of code by project as influenced by a 
number of product conditions and requirements [Ref. 31]. The 
model is derived from a database of 60 different projects. 
One of the goals of Walston and Felix was to develop an effort 
estimation model based on size alone. Based on their 
collected data they found 29 factors which were significantly 
correlated with productivity. They incorporated these factors 
into a single formula which enabled them to calculate a 
productivity index. Using this productivity index and linear 
regression (for calibrating their model to the environment), 
they developed an equation for estimating productivity of new 
projects. 
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7. Boeing Model 

The Boeing model was developed by Boeing Computer 
Services in 1977 [Ref. 32]. The model is considered to work 
best for aerospace types of systems for which it estimates 
total project effort. In estimating effort the model uses a 
set of productivity rates applied to the following types of 
software used in the model: 

Mathematical Operations, 

Report Generation, 

Logic Operations, 

Signal Processing or Data reduction. 

Real Time. 

The Boeing model also uses estimates on the total 
number of delivered instructions for developing its effort 
estimation of nominal man-months. Like many other models, it 
uses predetermined percentages to divide the total estimated 
effort into individual effort estimates for the various life 
cycle phases. Finally, the model applies effort multipliers 
to the nominal effort estimates for each phase to produce an 
adjusted effort estimate for each phase. 

8 . GRC Model 

The General Research Corporation (GRC) model was 
developed in 1974 [Ref. 33]. The model is a static, single¬ 
variable model which estimates cost in a non-linear fashion. 
The model uses a large number of different estimating 
techniques including regression analysis. The model has a 
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number of good features which include a thorough definition of 
the quantities being estimated and a set of relationships for 
estimating such quantities as training and installation costs. 
However, it does have a few problem areas the least of which 
includes using the "number of output formats" as the basic 
size parameter [Ref. 19;p. 519]. 

9. Other Models 

In addition to the previously listed models there have 
been many other software cost estimation models recently 
developed, some of these include the Bailey-Basili Meta-Model 
[Ref. 34], Grumman SOFCOST model [Ref. 35], Tausworthe Deep 
Space Network (DSN) model and subsequent SOFTCOST model [Ref. 
36], Jensen model [Refs. 37; 38], Estimacs model [Refs. 39; 
40], SPQR/20 model [Ref. 41], Before You Leap (BYL) model 
[Ref. 42], and the BIS/Estimator model [Ref. 43]. 

Most of these models have been automated and use 
either SLOG or function points as their primary input size 
metric. Since the automated models are continually under 
revision, the software vender should be contacted for the 
latest information regarding the model. 

C. SUMMARY 

Although there are many models currently available for 
estimating software cost, a model has yet to be developed 
which can estimate software cost with a high degree of 
accuracy. Furthermore, none of the discussed estimation 
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models appear to be conducive to DSS software. Nevertheless, 
the COCOMO [Ref. 19] and Function Point [Refs. 17; 18] models 
have proved to be key models in leading the research for the 
development of better cost estimation models. Therefore, they 
lend themselves as the best candidates to be tailored to the 
DSS environment. These two models will be presented in the 
following two chapters. 





V. COCOMO MODEL 


A. OVERVIEW 

The COCOMO model which stands for Constructive COst Model 
was developed by Barry Boehm and is covered in great detail in 
[Ref. 19]. Based on his analysis of 63 software development 
projects, Boehm developed a model that relates SLOC inputs to 
effort. The COCOMO model consists of three separate forms of 
the model: Basic, Intermediate, and Detailed. Each model is 
further broken down into three modes of software development: 
organic, semidetached and embedded. These modes are used to 
identify the development environment and general characteris¬ 
tics of a software project such as size and complexity. 

The ICEM model, presented in Chapter VII, will automate 
the functions of the Basic and Intermediate models. Since the 
Detailed model will not be implemented in ICEM it is not 
discussed in this chapter. 

B. BASIC MODEL 

The Basic COCOMO model is used to make guick, early, rough 
order of magnitude estimates of small-to-medium-sized software 
projects. The Basic model uses an estimated number of 
thousands of delivered source instructions (KDSI), and the 
development mode to estimate the development time and cost of 
a software development project. 
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Source instructions are defined as executable lines of 
code which include variable declarations, format statements 
and job control language but not comment statements [Ref. 
19:p. 59]. All COCOMO models rely on fairly accurate 

estimates of KDSI in order to make accurate estimates. 

As previously mentioned, the development mode of a project 
is determined by its characteristics such as size, complexity, 
and design environment. A summarized list of Boehm's criteria 
[Ref. 19:pp. 78-82] for the different modes follows: 

- ORGANIC MODE 

* Generally stable development environment, 

* Minimal need for innovation in architectures of 
algorithms, 

* Relatively low premium on early completion of the 
project, 

* Relatively small size, usually not greater 
than 50 KDSI, 

* Small experienced software development teams used, 

* Loose coupling with external systems. 

- SEMIDETACHED MODE 

* Mixture of organic and embedded characteristics, 

* Intermediate level of experience with related 
systems, 

* Wide mix of experienced and inexperienced people, 

* Some experience with aspects of system under 
development, 

* Software project range usually not greater 
than 300 KDSI. 
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EMBEDDED MODE 


* Software development within tight constraints such 
as time and cost, 

* Integral part of some larger system, heavily 
embedded and strongly coupled to it, 

* Numerous interface requirements, 

* High required reliability, 

* Requires much innovation. 

The Basic COCOMO effort estimating equations as 
separated by mode are as follows: 

Organic Mode MM = 2.4(KDSI)^“ 

Semidetached Mode MM = 3.0(KDSI)^ ^^ 

Embedded Mode MM = 3.2 (KDSI) 


where: 

MM = man-months of development effort 

KDSI = thousands of delivered source instructions. 

These equations are used primarily to obtain an estimated 
number of man-months required for project development. Labor 
cost is not directly calculated due to price variances among 
organizations. However, labor cost may easily be obtained by 
multiplying the man-month values by an appropriate average 
man-month salary. It is recommended that the average man- 
month salaries be calculated separately for each major phase. 
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If desired an hourly rate can be determined by setting a man- 
month equal to 150 man-hours per month. [Ref. 19:p. 59] 

The development period covered by COCOMO, for which the 
above equations apply, begins at the beginning of the product 
design phase and ends at the end of the integration and test 
phase. The COCOMO model provides a method for dividing total 
cost among these phases and additionally provides equations 
for estimating annual software maintenance cost. These issues 
are covered in detail in [Ref. 19] and will not be discussed 
further. 

In addition to providing man-monch estimates the Basic 
COCOMO model also provides Development Time or (TDEV) 
estimates. TDEV represents the number of months required for 
project completion. It is often referred to as development 
schedule and is calculated from the following formulas: 


Organic Mode 

TDEV = 2.5(MM)°" 

Semidetached Mode 

TDEV = 2.5(MM)° “■ 

Embedded Mode 

TDEV - 2.5{MM)'^ '^ 


where: 

TDEV = development time in months 

MM = man-months as previously calculated. 
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C. INTERMEDIATE COCOMO 

One of the drawbacks in using the Basic model is that it 
is limited in accuracy because it does not take into account 
many factors which can effect software cost. Some of these 
factors include differences in hardware constraints, personnel 
quality and experience, and use of modern tools and 
techniques. The Intermediate COCOMO model was developed to 
incorporate these and other project attributes which are known 
to have a significant influence on software cost. The intent 
of adding these factors is to improve the accuracy of the 
model. The Intermediate model uses 15 cost drivers to make 
these adjustments. These cost drivers are grouped into four 
categories; 

Product attributes 

* RELY--required software reliability, 

* DATA--data base size, 

* CPLX--product complexity. 

Computer attributes 

* TIME—execution time constraint, 

* STOR—main storage constraint, 

* VIRT—virtual machine volatility, 

* TURN—computer turnaround time. 

Personnel attributes 

* ACAP—analyst capability, 

* AEXP—applications experience, 

* PCAP—programmer capabi?ity. 
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* VEXP—virtual machine experience, 

* LEXP—programming language experience. 

Project attributes 

* MODP—modern programming practices, 

* TOOL—use of software tools, 

* SCED—required development schedule. 

Each cost driver is ranked on a scale indicating its 
importance to a particular product. Figure 5.1 displays the 
ranking scale and their corresponding values with respect to 
the various cost drivers. Boehm [Ref. 19:pp. 119-122] 

explains how to properly rank each cost driver. 

Once all of the values for the cost drivers are obtained 
they are multiplied together to obtain a single product called 
the Effort Adjustment Factor (EAF). This factor is then 
applied to the effort equation to obtain an adjusted man-month 
calculation. 

The development modes for the Intermediate model are the 
same as those for the Basic model. However, the effort 
equations vary slightly from the Basic model and are as 
follows: 

Organic Mode MMn = 3.2(KDSI)^ °^ 

Semidetached Mode MMn = 3.0(KDSI)^ 

Embedded Mode MMn = 2.8 (KDSI) 

where; 
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Figure 5.1 Software Development Effort Multipliers 
[Ref. 19:p. 118] 


MMn = Nominal man-months of development effort. 

The effect of the cost drivers is factored into the effort 
equation by multiplying the nominal man-months by the EAF: 

MMadj = MMn * EAF 

where: 

MMadj = man months adjusted. 
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The schedule formulas by mode are the same as for the 
Basic model. 

D. CALIBRATING THE COCOMO MODEL 

The term calibration is used to mean that new coefficients 
or multipliers for an existing model are established or 
modified such that the same model structure applies to a 
database or an individual system corresponding to an 
environment other than the one upon which the model was 
developed. 

In general, the COCOMO model was developed for most 
software cost estimations situations. However, by calibrating 
the COCOMO model to the user's specific environment the 
accuracy of the model can be greatly increased. Boehm [Ref. 
19:pp. 524-528] provides two ways to calibrate the COCOMO 

model. The easiest way is to first determine the most 
appropriate development mode to be used. Then a least-squares 
approximation technique is used to recalculate the constant 
term (c) in the development mode's effort equation: 

MM = c(KDSI)‘’(EAF) 

The least-squares technique produces the following equation 
which is used to calculate the new constant (c): 
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n 

E ^i!?i 

i = 0 _ 

n 

i*0 


where: 

MMi = actual man-months of effort 
Q, = (KDSIJ^^CEAFJ 
b = scale factor for mode 
n = number of projects in database. 

The second method for recalibrating the COCOMO model uses 
a similar least-squares method for calibrating both the 
coefficient term (c) and the scale factor (b). These values 
are recalibrated to the user's environment by using the 
following equation: 


logc = 


^ 2 ^ 0 - 


b = 




where: 

the quantities ao, aj, a 2 , do and di are calculated as: 
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^0 

n 

= E log(KDSI)_i 

i«0 

n 

a. = ^ [log (KDSI) i] 2 

i=C 

n 

do = (MM/EAF)^ 

i=0 

n 

dl = 5]) log(MM/EAF) ^ log(KDSI)i 

i-0 


As is apparent, neither of these methods provides a way to 
recalibrate the cost driver rating values. Unfortunately, the 
only method to recalibrate the cost drivers is through trial 
and error and this is not recommended due to the multiplica¬ 
tive nature of the EAF factor. 

The ICEM model presented in Chapter VII uses this least- 
squares method in order to recalibrate the model to the unique 
environment of Decision Support Systems. 
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VI. FUNCTION POINT ANALYSIS MODEL 


A. BACKGROUND 

In 1979, Alan Albrecht of IBM developed the method of 
Function Point Analysis [Ref. 17], to help measure the size of 
a computerized business information system. He found that he 
could not successfully use the SLOC method to determine size 
measurements which were needed as an input component for 
effort and productivity estimates. As an alternative to using 
SLOC, he developed the Function Point Analysis method. He 
further revised and refined his method in 1983 [Ref. 18]. 

As previously mentioned, there are very few cost 
estimation models that can be applied relatively early in the 
systems development life cycle. This is because they rely on 
metrics that can only be applied in the post~code phase of 
development such as SLOC. The function point metric is an 
exception to this rule. 

By being able to make estimates early in the development 
process one can continue to refine the cost model throughout 
life cycle development. Furthermore, early estimates can 
improve scheduling and reduce cost. Another advantage of the 
function point metric is that, unlike SLOC, it is unaffected 
by the choice of programming languages used. 
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B. CALCULATING FUNCTION POINTS 

In addition to Albrecht's articles, there have been 
several noteworthy publications written which provide a step 
by step method for calculating function points. Brian Dreger 
[Ref. 44] provides a highly-detailed guideline for calculating 
function points while Roger Pressmen [Ref. 20] provides an 
easy to use table format. Figure 6.7 provides a similar 
format to be used as a worksheet for making function point 
calculations. 

The method for calculating function points involves a four 
step process: 

Count the unique number of occurrences of the five user 
function types, 

Classify each function type according to its level of 
complexity. 

Adjust for processing complexity, 

Make the function points calculation. 

C. (STEPS 1 & 2) COUNT AND CLASSIFY FUNCTION TYPES 

Five types of functions are counted as function points: 
Inputs. 

Outputs, 

Inquiries, 

- Files, 

Interfaces. 

Each of these functions are classified according to 
three levels of complexity; 
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simple, 

Average, 

Complex. 

These complexity factors are further associated with a 
particular weighting factor which is used in (Step 3) to 
adjust the values of the five individual function counts. 

1. Measuring Inputs 

In measuring inputs, each unique user data or control 
input that is performed by the user within the application in 
order to add, delete or update something should be counted. 
An input is considered unique if it has a different format, 
such as a different input screen, or it has the same format as 
another input but uses different processing logic (same 
entities are modified in a different way). Inputs should be 
distinguished from inquiries, which are counted separately. 
After the number of inputs are counted they are classified 
according to their complexity. 

a. Classifying Inputs 

Classifying inputs for complexity depends on two 
things: the number of files referenced or accessed (see 

measuring files below) and the number of data items (fields or 
specific variables) referenced. It is important to note that 
only the data items actually updated by the input transaction 
are counted. Data items which reside in the same file but are 
not referenced are not counted. The complexity level and 
associated weighting factor is selected by cross-referencing 
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the numbers of files referenced to the number of data items 
referenced. Figure 6.1 is used to determine the complexity 
level and the corresponding complexity weighting factor. 



1-4 data items 
referenced 

5-15 


16 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(3) 

Simple 

(3) 

Average (4) 

2 files 
referenced 

Simple 

(3) 

Average 

(4) 

Complex (6) 

3 or more 
files ref. 

Average 

(4) 

Complex 

(6) 

Complex (6) 


Figure 6.1 Classifying Inputs 


From this chart it may be seen that ten data items 
accessed from two files would be classified as "average" in 
complexity and given a weighting factor of four. 

2. Measuring Outputs 

In measuring outputs, each unique user data or control 
output procedurally generated that leaves the application 
boundary should be counted. This includes reports and 
messages to the user, as well as outputs to other applica¬ 
tions. Uniqueness has the same implications for outputs as it 
does for inputs. 

a. Classifying Outputs 

Outputs are classified in a similar format as 
inputs. However, the actual numerical values for the various 
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entries have been changed. Only the files and individual data 
items accessed during output are counted. Figure 6.2 is used 
to obtain the complexity level and corresponding weighting 
factor for outputs. 



1-5 data items 
referenced 

6-19 

20 or more 
data items 

0 or 1 file(s) 
referenced 

Simple (4) 

Simple (4) 

Average (5) 

2-3 files 

Simple (4) 

Average (5) 

Complex (7) 

4 or more 
files ref. 

Average (5) 

Complex (7) 

Complex (7) 


Figure 6.2 Classifying Outputs 


3. Measuring Inquiries 

In measuring inquiries, each unique input/output 
combination in which the on-line user-defined input causes and 
generates an immediate on-line output by the application 
should be counted. Inquiries may also be provided to other 
applications. Many inquiries are simply requests for specific 
data from a data base. An inquiry is considered unique if it 
has a format different from others in either its input or 
output portions or it has the same input and output format but 
requires different processing logic in either. 
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a. Classifying Inquiries 

Classifying inquiries consists of two parts: 
classifying the inputs and classifying the outputs. The same 
charts are used for inputs and outputs as before. The only 
difference is that while a stand-alone input actually updates 
the data store, an inquiry only directs the search and never 
updates. Once the two complexity factors are obtained for 
outputs and inputs the two are compared with the larger value 
being selected as the weighting factor for the inquiry 
function. 

Figure 6.3 is used to obtain the respective 
classification and weighting factor for the input part of the 
inquiry function, while Figure 6.4 is used to obtain the 
output factor. The larger value of the two is used as the 
factor for the inquiry function. 


Input part: 

1-4 data items 
referenced 

5-15 


16 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(3) 

Simple 

(3) 

Average 

(4) 

2 files 
referenced 

Simple 

(3) 

Average 

(4) 

Complex 

(6) 

3 or more 
files ref. 

Average 

(4) 

Complex 

(6) 

Complex 

(6) 


Figure 6.3 Classifying Inquiries (Input) 
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Output Part: 

1-5 data items 
referenced 

6-19 


20 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(4) 

Simple 

(4) 

Average 

(5) 

2-3 files 

Simple 

(4) 

Average 

(5) 

Complex 

(7) 

4 or more 
files ref. 

Average 

(5) 

Complex 

(7) 

Complex 

(7) 


Figure 6.4 Classifying Inquiries (Output) 

4. Measuring Files 

Measuring the number of files is not as simple as 
just counting the number of physical files in an application. 
Rather, only files that contain data stored in logical 
groupings within the application are counted as files. These 
files perform data storage functions for the application. 
Furthermore, files or data stores are to be considered in the 
logical not physical sense. A physical file can actually 
contain many logical files. Every unique data access, path or 
view of a database is considered a collection of information 
and is counted as a separate logical internal file. However, 
temporary data stores are excluded from this count as only 
permanent files are counted. Additionally, transactions that 
trigger internal logical files to be updated or changed are 
not considered files themselves. 

It is crucial that the number of logical internal 
files be properly counted. Typically, every logical file will 


45 




have at least one input, output, and inquiry. This 
corresponds to at least 18 points when complexity adjustments 
are added (seven file, three input, four output, and four 
inquiry). 

a. Classifying Files 

Like the other classifications, classifying files 
is a two-step process. First the number of data items 
actually required by the application are counted and then 
either the number of record forma'^s within the file or the 
number of logical relationships in which the file participates 
are counted. It is important to recognize that only logical 
relationships are used; therefore, the number of different 
record types within a file are not simply counted but also 
their logical relationships as well. Figure 6.5 is used to 
determine the complexity level and weighting factor for files. 



1-19 data 
items ref. 

20-50 


51 or more 
data items 

1 logical record 
format/relation¬ 
ship 

Simple (7) 

Simple 

(7) 

Average (10) 

2-5 logical 
record format/ 
relationships 

Simple (7) 

Average 

(10) 

Complex (15) 

6 or more 
logical record 
format/relation¬ 
ships 

Ave. (10) 

Complex 

(15) 

Complex (15) 


Figure 6.5 Classifying Files 
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5. Measuring Interfaces 

liiterfaces involve using data stored by another 
application but used by the current application. In measuring 
interfaces count every major logical file (as previously 
defined) within the application boundary that is sent to, 
shared with, or received from another application. Files 
shared between applications are counted as both files and 
interfaces within each application if they are used in both. 
This includes data stores that are imported, exported or 
shared between the two applications. Interface does not 
involve transaction. An application must be able to access 
the data directly without the aid of another application for 
it to be counted as an interface. 

a. Classifying Interfaces 

The classification scheme used for interfaces is 
similar to the one used for files. As Figure 6.6 demonstrates 
the number of data items referenced (and actually used) and 
the number of logical relationships in which the interface 
file participates to meet application requirements are used to 
obtain the complexity level and weighting factor. 
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1-19 data 

20-50 


51 or more 


items ref. 



data items 

1 logical record 
fonnat/relationship 

Simple (7) 

Simple 

(7) 

Average (10) 

2-5 logical 
record format/ 
relationships 

Simple (7) 

Average 

(10) 

Complex (15) 

6 or more 

Ave. (10) 

Complex 

(15) 

Complex (15) 

logical record 
format/relationships 






Figure 6.6 Classifying Interfaces 


D. (STEP 3) ADJUST FOR PROCESSING COMPLEXITY 

Adjusting for processing complexity is a simple task; 
simply multiply the measured value for each function (count) 
by its corresponding weighting factor. Figure 6.7 provides a 
worksheet for developing function points and shows how the 
weighting factor is incorporated into the process of 
calculating the function point value. 
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I 

! 

I Function 

1 

1 

Count 

Weighting factor 


Simple 

Avg. 

Complex 

FP 

1 Inputs 


3 

4 

6 1 

_1 

1- 

1 Outputs 

-1 

4 

5 

■7 


Inquiries 

i 

-1 

3 

4 

6 1 

1 Files 

1 


7 

10 

15 


Interfaces 

1 


5 


10 



'Count X weighting factor = FP Sum of all FP = 


Figure 6.7 Function Point Worksheet 


E. (STEP 4) MAKE THE FUNCTION POINTS CALCULATION 

To make the total adjusted function points calculation 
(FP) the following equation is used: 

FP = (Sum of FP counts) X [0.65 + (0.01 X SUM(Fi))] 

where (Sum of FP counts) is the total sum of FP counts 
obtained from above and the SUM(Fi) is the sum of 14 
complexity adjustment values (where i = 1-14) obtained by 
answering the questions in Figure 6.8 according to the ranking 
scale provided. 
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Rate each factor on a scale of 0 to 5: 


0 1 2 3 4 5 



influence Incidental Moderate Average Significant Essential 

Fi: 

1. Does the system require reliable backup and recovery? 

2. Are data communications required? 

3. Are there distributed processing functions? 

4. Is performance critical? 

5. Will the system run in an existing, heavily utilized 
operational environment? 

6. Does the system require on-line data entry? 

7. Does the on-line data entry require the input 
transaction to be built over multiple screens or 
operations? 

8. Are the master files updated on-line? 

9. Are the inputs, outputs, files, or inquiries complex? 

10. Is the internal processing complex? 

11. Is the code designed to be reusable? 

12. Are conversion and installation included in the design? 

13. Is the system designed for multiple installations in 
different organizations? 

14. Is the application designed to facilitate change and 
ease of use by the user? 


Figure 6.8 Complexity Adjustment Factors 
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F. SUMMARY 


The four step method we have followed has only one goal in 
mind, to calculate a single function point number. It is 
important to note that this number is only a representation of 
the size of the project. Like SLOG it is only used as a 
sizing metric and therefore does not yield an effort 
estimation directly. However, as demonstrated by Albrecht and 
Gaffney in 1983 [Ref. 18], one can use simple linear 
regression on a data set of projects to estimate man-months as 
a function of the function points. This is the method used in 
developing the ICEM model. 
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VII. INTELLIGENT COST ESTIMATION MODEL flCEM^ 

A. INTRODUCTION 

The ICEM model is an integrated automated package which 
utilizes an expert system coupled with a spreadsheet to 
perform cost estimation. The model was developed as an 
initial prototype system. It is not intended to be an all- 
inclusive model ready to be implemented within an organiza¬ 
tion. Rather, it is used to analyze existing methodologies 
and promote the development of integrated cost estimation 
models which incorporate expert system technology. 

One of the key factors in accurately estimating cost is 
user experience. All too often this experience is lost when 
personnel transfer. The ICEM model is considered intelligent 
because it uses an expert system to collect and process 
heuristic data. An expert system j used because it enables 
an organization to capture the talent and experience of its 
key personnel [Ref. 45:p. 332]. By using an expert system as 
the foundation for the model we hope to promote the capturing 
of this experience so it can be used in designing and 
continually upgrading an effective cost estimation model. 

Additionally, the expert system enables the quick 
development of a very user-friendly system. The expert system 
uses a simple question and answer format to collect data for 
its parametric models. This eliminates the need for the user 
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to perform exhaustive searches through data tables to obtain 
appropriate data values which must then be applied to 
equations for manual calculations. 

The main problem with almost all of the cost estimation 
models discussed in Chapter IV is that they are poor 
estimators. This point was emphasized by Boehm [Ref. 19:p. 
32] who said: 

Today, a software cost estimation model is doing well if 
it can estimate software development cost within 20% of the 
actual costs, 70% of the time, and on its own home turf 
(that is, within the class of projects to which it is 
calibrated). 

Most of this low accuracy rate is due to undersizing. 
But, even as weak as these cost estimation models may appear, 
they still offer marked improvements over previously used 
manual methods and if properly used can be very beneficial. 

In an effort to improve the accuracy of the estimating 
process the ICEM models incorporates the concepts developed by 
the COCOMO and Function Point models into an integrated model. 
These two models were selected based on their popularity and 
success [Ref. 5]. Also these two models proved ideal because 
they utilize two very dissimilar estimating methods and 
incorporate two different size metrics (SLOC and Function 
Points) for their primary input. For the purpose of consis¬ 
tency checking it is important to have as much independence in 
the estimating methods as possible. 

The ICEM model is actually three models in one. The 
COCOMO Intermediate model has been automated for all modes of 
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operation including organic, semidetached and embedded modes. 
The second model specifically tailors the COCOMO organic mode 
for the DSS environment. The organic mode was considered 
because of the characteristics of the empirical database which 
is used to calibrate the model. The third model includes a 
parametric model which incorporates the Function Point size 
metric. 

In order for any cost estimation model to be useful in an 
environment other than the one in which it was developed, it 
must be calibrated to the new environment. One of the 
requirements for tailoring a cost estimation model to a new 
environment is to have a proper database. To ensure 
statistical quality, a database of at least ten projects 
unique to the new environment is recommended as a starting 
point. The ICEM model is calibrated to the Decision Support 
System (DSS) environment by using a database set of 13 DSS 
projects. 

B. OVERALL ARCHITECTURE OF ICEM 

The architecture of the ICEM model is displayed in Figure 
7.1. VP-Expert, developed by Paperback Software Internation¬ 
al, provides the primary interface with the user. Although 
several expert systems are currently on the marketplace today, 
VP-Expert was selected based on its low cost, ease-of-use, 
powerful expert system capabilities, and ability to be easily 
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coupled with spreadsheet (VP-Planner) and database (VP-INFO) 
systems. 



Figure 7.1 ICEM Architecture 


1. VP-Expert 

VP-Expert consists of three parts: a user interface, 
a knowledge base, and an inference engine. The user 


55 









interface allows the user to coininunicate with the expert 
system through the keyboard and screen display. In VP-Expert, 
the knowledge base is stored in files that have the extension 
".KBS." The knowledge base itself is composed of three 
sections: actions block, rules block, and guestions block. 

The actions block of the knowledge base provides 
directions to the expert system for finding a particular 
solution to a problem. It controls the flow of the program. 
On the other hand, the rules block contains the rules that 
tell VP-Expert how to solve a specific problem. It consists 
of three key words: RULE, IF, and THEN. The guestions block 
provides questions to ask the user if VP-Expert needs more 
information. 

Finally, the inference engine contained in VP-Expert 
provides decision-making intelligence. The inference engine 
uses the rules in the rule base in order to make decisions on 
how to solve a problem. Typically, an expert system’s 
inference engine can use two methods for processing the rule 
base, either forward chaining or backward chaining. The ICEM 
model was developed to employ a backward chaining strategy for 
problem solving. 

The ICEM model incorporates two knowledge bases, 
ICEMl.KBS and ICEM2.KBS, which have been chained together. 
One of the main problems with using a rule-based expert system 
is that depending on the size of the rule base the system 
could require a considerable amount of memory usage. In order 





to get around this memory barrier VP-Expert allows two rule 
bases to be chained together. 

In VP-Expert, when a knowledge base is chained to a 
second knowledge base, variable values are first stored in a 
temporary file using the "SAVEFACTS" command. The second 
knowledge base (with its new rule base) then replaces the 
first rule base in memory. Finally, it recovers the stored 
variable values using the "LOADFACTS" command. This method 
saves considerable memory by swapping knowledge bases and 
their accompanying rule bases. 

One minor inconvenience of using the "SAVEFACTS" 
command is that it will save the value of every variable used 
by any portion of the expert system resulting in irrelevant 
data passing from one knowledge base to another. In order to 
eliminate unnecessary data passing all variable values can be 
cleared from memory using the "RESET ALL" command and then 
pertinent variables can be assigned specific values before 
using the "SAVEFACTS" command. By using the "RESET ALL" 
command and chaining its two knowledge base files (ICEMl.KBS 
and ICEM2.KBS) together, the ICEM model is able to save 
considerable memory thus enabling it to operate within the 
boundaries of conventional memory. Further information about 
VP-Expert and its command language may be found in [Ref. 46]. 

2. VP-Planner Plus 

As shown in Figure 7.1, VP-Expert is coupled to VP- 
Planner Plus. VP-Planner Plus is a spreadsheet program also 
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developed by Paperback Software International. It is used to 
provide automated statistical calculations and display effort 
and schedule information in a format easily understood by the 
user. It is fully automated and allows instantaneous 
sensitivity analysis to be performed by the user. All 
variable values are passed from VP-Expert to VP-Planner using 
the "PWKS" command. Although this command works relatively 
well, it has a tendency to be time-consuming. It takes 
approximately 20-30 seconds to save values to the spreadsheet 
using an IBM compatible 386 while a 286 machine may take one 
to two minutes for processing. 

Although there are many advantages to linking VP- 
Expert to VP-Planner there is also one additional disadvan¬ 
tage. When the two programs are linked together they are 
essentially running simultaneously. Therefore, almost twice 
the amount of memory is required than if only one of the 
programs was running at a time. This posed a significant 
challenge in trying to keep the memory usage under 600k. 
Unfortunately, there is no way around this problem. VP-Expert 
does not offer a method to call a specific spreadsheet using 
VP-Planner unless VP-Expert is running in the background. 

All user data are saved in spreadsheet files that end 
with the ".WKS" extension. Further information about VP- 
Planner Plus and its related commands may be found in [Ref. 
47] . 
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VIII. USING ICEM FOR EFFORT ESTIMATION OF DSS SOFTWARE 


A. INTRODUCTION 

The purpose of this chapter is to use ICEM as a DSS in 
order to estimate the amount of effort required to develop PC- 
based DSS. As discussed earlier, ICEM combines the COCOMO 
model and the Function Point models. But before these models 
can be incorporated into ICEM, it is first necessary to 
recalibrate their estimated coefficients to take into 
consideration environmental factors related to DSS. 

As can be seen later in this chapter, recalibration is 
particularly necessary, especially when you consider that the 
original coefficients developed by Boehm for the COCOMO model 
were derived from large-scale projects using second generation 
programming language (2GL) that were developed two decades 
ago. On the other hand, the majority of DSS are developed by 
small programming groups using either third or fourth 
generation programming languages (4GL). 

Although ICEM was designed to incorporate both the COCOMO 
and function points methodologies, only the COCOMO model has 
been calibrated due to the unavailability of empirical data. 

B. THE DSS DATABASE 

The DSS database, which the ICEM model uses for calibra¬ 
tion, comprises 13 DSS projects which were built at the Naval 
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Postgraduate School (for more information regarding these 
projects, contact the thesis's advisor). All of these DSS 
were developed under the conditions described by the COCOMO 
organic mode (see definition. Chapter V, Section D) . Table 
8.1 reproduces the data points for the various DSS projects. 
A brief description of each of the 13 DSS project follows. 


TABLE 8.1 
DSS DATA POINTS 


Project 

]- - 

Language 

KDSI ; 

EAF 

MMact 

#dev : 

CO-OP 

i Turbo Pascal 

16.0 

0.94 

15.0 

1 

INTEG 

Basic 

3.0 ' 

1.15 

7.0 

2 

CEA 

Turbo Pascal 

9.0 

0.90 

7.0 

1 

TAO 

Exsys 

4.0 

0.85 

6.0 

1 

CEASAR 

Exsys 

5.0 

0.98 

5.0 

1 

NURSE 

Turbo Pascal 

5.0 

1.26 

9.5 

1 

ASDB 

dBase III 

6.0 

1.00 

6.5 


COCOMO 

Knowledgeman 

3.0 

1.30 

7.5 

c 

NAVAIR 

dBase III 

2.5 

0.90 

6.5 

3 

CAI 

dBase III 

2.5 

1.50 

8.0 

2 

STOCKPT 

VP-Expert 

6.0 

1.00 

4.0 

1 

DIST.ES 

VP-Expert 

6.5 

1.10 

3.0 

1 

TOUCHSTONE 

Turbo Pascal 

9.5 

1.00 

8.0 

2 


1. Co-Op 

Co-Op is a group DSS for multiple-criteria decision 
making. Co-Op contains a set of techniques of aggregation of 
preferences and consensus seeki ig algorithms that can be used 
in conjunction with individual multiple criteria decision 
models. 
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INTEG 


2 . 

INTEG is a Software package to assist in the 
instruction of an introductory graduate level course in 
probability and statistics. INTEG is designed to increase 
student productivity during time spent on learning various 
problem- solving techniques. 

3. CEA 

CEA is a DSS for cost-effectiveness analysis for 
control and security of computer systems. CEA is geared to 
help the EDP manager: (i) identify alternative sets of 
control activities, (ii) evaluate and choose the most 
preferred set, and (iiM monitor and upgrade the security of 
EDP system frequently. 

4. TAP 

TAP is a rule-based system to help Tactical Action 
Pfficers (TAP) to assess the threats of enemy's weapon systems 
and to determine appropriate c. measures during a naval 
engagement. 

5. CEASAR 

CEASAR is an expert system i,. computerize the manual 
assignment selection system for Army commissioned officers at 
the Military Pert.annel Center (MILPERCEN) . The system is 
designed to minimize adversary relationships that often exist 
between officers in the field and their assignment specialists 
from the U.S. Army Military Personnel Center. 
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6. 


NURSE 


NURSE is an expert system to automate the Nursing 
Diagnosis, Nursing Care Plan and Patient Classification Level. 
NURSE passes this information to another program to determine 
nursing staffing. 

7. ASDB 

ASDB is a DSS to support the management and 
accountability of the property of an academic department. 
ASDB is an intelligent DBMS that provides customized reports 
including custodian listings, quarterly reports, and property 
reports. 

8. COCOMO 

COCOMO is a DSS to perform sensitivity analysis of the 
COCOMO models including phase distribution calculation for 
development or maintenance, activity distribution by phase for 
development, and report generation. 

9. Navair 

Navair is an automated evaluation tool to estimate 
Aircraft System Test and Evaluation (AST&E) efforts. A 
relational DBMS is coupled with a statistical software package 
to estimate AST&E cost drivers and physical/performance 
characteristics. 

10. CAT 

CAI is an intelligent computer-aided instruction 
software system based on the Baysesian Probabalistic Model. 
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The system is able to function beyond the usual stand-alone 
mode through interfacing with an external DBMS. 

11. Stock Point Expert System 

The Stock Point Expert System is an expert system for 
causative research in inventory management. Four technical 
areas of causative research are implemented using four 
separate knowledge bases. The Stock Point Expert System seeks 
to improve productivity and assists with training in the 
causative research area of inventory management. 

12. Distributed Expert System 

The Distributed Expert System is a distributed expert 
system to provide the submarine Ship's Duty Officer (SDO) 
preventive maintenance expertise for the safe and effective 
execution of all maintenance aboard ship. The preventive 
maintenance knowledge is drawn from a variety of sources of 
expertise stored in different knowledge bases that are 
physically dispersed in a network of personal computers. 

13. Touchstone 

Touchstone is a criteria development program for group 
DSS. Based on the Delphi brainstorming technique. Touchstone 
is a text-based GDSS to help group members generate problems 
and explore solutions. 

C. CALIBRATING THE COCOMO MODEL FOR DSS 

Using ICEM and its 13-project DSS database, the calibrated 
Intermediate COCOMO equation is shown below: 
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MM = 1.69 KDSI * EAF. 


Table 8.2 reproduces the estimated efforts (MMest) and the 
adjusted effort values (MMadj), using the calibrated 
Intermediate COCOMO model incorporating the above equation. 
The Effort Adjustment Factors (EAFs) were derived from close 
observations of the projects. Detailed description of the 
conditions under which these software were developed can be 
found in the related technical reports or theses (for more 
information regarding the computation of the cost drivers, 
contact the thesis' advisor). 


TABLE 8.2 

EFFORT ESTIMATES USING CALIBRATED INTERMEDIATE 
ORGANIC COCOMO MODEL 


Project 

KDSI 

EAF 

MMest 

MMadj 

%ERR 

CO-OP 

16.0 

0.94 

: 13.72 

12.89 

-14 . 

, 00 

INTEG 

3.0 

1.15 

3.88 

14.46 

-36. 

. 00 

CEA 

9.0 

0.90 

8.89 

8.00 

14 , 

, 00 

TAO 

4.0 

0.85 

4.82 

4.10 

-31. 

,60 

CEASAR 

5.0 

0.98 

5.70 

5.59 

11. 

,80 

NURSE 

5.0 

1.26 

5.70 

7.18 

-24 . 

,40 

ASDB 

6.0 

1.00 

6.54 

6.54 


,62 ; 

COCOMO 

3.0 

1.30 

3.88 

5.04 

-32 . 

.80 

NAVAIR 

2.5 

0.90 

3.38 

3.04 

-62. 

.00 

CAI 

2.5 

1.50 

3.38 

4.22 

5. 

.50 

STOCKPT 

6.0 

1.00 

6.54 

6.54 

118. 

.00 ; 

DIST.ES 

6.5 

1.10 

6.59 

7.65 

-4 . 

,30 

TOUCH 

9.5 

1.00 

9.26 

9.26 

42. 

.40 

% Mean Error = -1. 

Sum of the squared 

,0% 

errors 

= 72.22 
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Table 8.3 reproduces these efforts using Boehm's Inter¬ 
mediate Organic COCOMO model which has not been calibrated to 
the DSS environment. 


TABLE 8.3 

EFFORT ESTIMATES USING NON-CALIBRATED INTERMEDIATE 
ORGANIC COCOMO MODEL 


Project 1 

KDSI 

EAF 

MMest 

MMadj 

%ERR ! 

CO-OP ; 

16.0 

0.94 

58.81 

55.28 

268.53 

INTEG 

3.0 

1.15 

10.16 

11.66 

66.57 

CEA 

9.0 

0.90 

32.14 

28.93 

313.29 i 

TAO 1 

4.0 

0.85 

13.72 

11.66 

94.33 i 

CEASAR 

5.0 

0.98 

17.34 

16.99 

239.80 

NURSE 

5.0 

1.26 

17.34 

21.85 

130.00 

ASDB 

6.0 

1.00 

21.00 

21.00 

223.08 

COCOMO 

3.0 

1.30 

10.14 

13.18 

75.73 : 

NAVAIR 

2.5 

0.90 

8.38 

7.54 

-5.75 i 

CAI 

2.5 

1.50 

8.38 

12.56 

214.00 

STOCKPT 

6.0 

1.00 

21.00 

21.00 

600.00 

DIST.ES 

6.5 

1.10 

22.84 

25.12 

214.00 

TOUCH 

9.5 

1.00 

34.02 

34.02 

423.38 

% Mean Error =219 

,77% 




Sum of the 

squared 

errors = 

4143.88 




D. DISCUSSIONS 

Based on the data gathered in Tables 8.1, 8.2 and 8.3, a 

number of observations can be made: 

As expected, estimations using the calibrated model is by 
far much more closer to actual figures. The percentage 
means of errors are -1% and 220% for the calibrated and 
non-calibrated models respectively. The sum of the 
squared errors drops from 4143.88 to 72.22 when using the 
calibrated model. 

Actual MMs of DSS projects using software generators such 
as expert systems shells (i.e., VP-Expert, Exsys), data 
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base management systems (dBase III), or spreadsheet 
(i.e., Knowledgeman) are significantly lower than 
estimated MM. This suggest that DSS generators do help 
increase software productivity. The difference in using 
4GL as opposed to 2GL was demonstrated by Verner and 
Tate, who found that using 4GL to build a DSS reduced 
development effort and schedule compared with Cobol in 
all phases of the life cycle except the requirements 
phase. [Ref. 48] 

The data also suggest that small-size, organic DSS, 
projects developed by one person appear to require less 
effort than those involving more than one person. The 
COCOMO effort adjustment factor (EAF) does not take into 
consideration the number of people associated in the 
software development. It is suspected that interpersonal 
communications as well as coordination and division of 
labor contributed to these discrepancies. However, it is 
not evident that there is a direct linear relationship 
between the number of personnel working on a project and 
the total MM required. 

A final comment relates to the experience in counting 
function points for the 13 DSS. Unlike SLOC measure¬ 
ments, ex-post data gathering for function points has 
proved to be much more difficult. It is believed that 
this process would have been much easier and more 
accurate if data had been gathered during the early 
phases of the software development. Additionally, the 
Function Point model appears to be more adapted to be 
used in a structured analysis setting where one can use 
Data Flow Diagrams (DFDs) and Entity Relationship 
Diagrams (ERDs) for data gathering purposes. Unfortu¬ 
nately, none of the projects in the DSS database 
incorporated structured analysis techniques in their 
development. This made data gathering much more 
difficult and inaccurate. 
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IX. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

The purpose of this thesis was to provide a tool to 
facilitate the tailoring of software effort estimation tools 
to the small-scale, organic DSS environment. The most popular 
cost estimation models were reviewed in Chapters IV, V and VI. 
It was found that none of these techniques were conducive to 
a DSS software development environment. 

ICEM was implemented as a workbench to calibrate the 
COCOMO and the function point metrics for DSS (Chapter VII). 
Using a database of 13 projects, a calibrated COCOMO model was 
derived (Chapter VIII). As expected, the study has found that 
the calibration was a critical condition when using parametric 
models. The findings also revealed some weaknesses of the 
COCOMO models for DSS effort estimation. 

Because of the inherent inaccuracies of estimation tech¬ 
niques, a model that can consistently estimate the effort and 
cost of software development with a high degree of accuracy 
still does not exist. However, by using a combination of 
modeling tools particularly tailored to the user's environ¬ 
ment, better estimates can be made. 

Cost estimation models should not be implemented with the 
intent of replacing the experienced estimator. Rather they 
should be used as a tool to assist the estimator. They should 
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be used to reinforce the estimator’s decisions not replace 
them. They can be also be used to perform sensitivity 
analysis and to keep track of the evolution of the cost 
patterns. ICEM was implemented with this concept in mind. 

B. RECOMMENDATIONS FOR FURTHER RESEARCH 

The calibrated equation for DSS proposed in Chapter VIII 
proved to be much more accurate than the original COCOMO 
equation. To further improve the accuracy of the model, the 
DSS database should be regularly updated and the model 
recalibrated. Due to environmental changes old projects in 
the database may have to be deleted as their information 
becomes obsolete or outdated while new data should be added to 
the database. It is recommended that ICEM be coupled with a 
database management system for that purpose. Additionally, if 
the size of the data permits, the model should be calibrated 
using subsets of data points according to the types of 
programming environment, DBMS, expert system shells, and 4GLs. 
By tailoring the model to the specific environment and 
programming language being used in the project, more accurate 
estimates are possible. Last but not least, the parameters 
used in the ICEM knowledge base to determine cost drivers were 
derived from large-scale projects. It is desirable that these 
factors also be calibrated to DSS environments to further 
improve the accuracy of the estimation. 
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APPENDIX A 


SAMPLE SESSION 


I. A TYPICAL ICEM CONSULTATION 


A. OVERVIEW 

This appendix is an example of a session using the Intelligent 
Cost Estimation Model (ICEM). The figures which follow are similar 
to actual screen outputs of the ICEM model as run on an IBM AT 
personal computer. In VP-Expert, the user highlights menu items to 
be selected. In this appendix, highlighted items are shown in bold 
and underlined type. The total run-time of a typical session is 
between five and ten minutes. 


B. RUNNING ICEM 

To start the ICEM model simply type GO and the welcome screen 
will be displayed. Figure A.l. If any key is depressed the next 
screen will be displayed, Figure A.2. The first option the user 
must decide is whether to retrieve a previously saved file. All 
previously saved files end with the extension .WKS, such as 
DSSCOC.WKS. Since VP-Expert requires the file name to be pre¬ 
specified within the knowledge base, only the following files may 
be retrieved: ORGANIC.WKS, SEMIDET.WKS, EMBEDDED.WKS, DSSCOC.WKS, 
and DSSFP.WKS. Since all spreadsheets are saved under these names 
the user is advised to copy all spreadsheets files that they would 
like to save to a new filename, otherwise ICEM will copy over the 
spreadsheet the next time it is run. If a file is saved under a 
different name then it may viewed by typing: VPP <filename>. To 
exit ICEM simply type /q when it is displayed at the bottom of the 
screen, depending on the user's location within the program it may 
be necessary to repeat the q or /q process to exit. 

Since a previously saved file was not retrieved, the next 
question addressed to the user is which model they would like to 
select. There are three different models available within ICEM: 
the intermediate COCOMO model for all modes of operation, the 
intermediate COCOMO model (organic mode) which has been calibrated 
to the DSS environment, and a parametric model which incorporates 
the Function Point size metric. 

For this session the COCOMO model calibrated for the DSS 
environment is selected. The next input the model requests is for 
an estimate of the number of thousands of lines of code the program 
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will have. Additionally, the COCOMO model requires 15 cost driver 
values which take into account factors effecting the estimation. 
The user must select one of the five options displayed for each of 
these cost drivers. Descriptions of each selection are provided to 
the user. 

Based on the user's inputs appropriate values are retrieved 
from the rule base and saved to the appropriate cells of the 
spreadsheet. The spreadsheet is then retrieved for the user. 
Figure A.3, displays appropriate output values. The final 
estimated value of the number of man-months required to complete 
the project is described as MMadj. To perform sensitivity analysis 
the user may change the number of KDSI or any of the values of the 
cost drivers, all output values are instantly recalculated. Only 
the cost driver values specified in Figure A4 should be used. 
Figure A.5 displays a sample output using the Function point model. 


Welcome to the ICEM model! 


The ICEM model is an integrated cost estimation model 
which uses an expert system to automate the Intermediate 
constructive Cost Estimation MOdel (COCOMO), developed by 
Barry W. Boehm and the Function Point Model, developed by 
Allen Albrecht. Both of these models have been tailored to 
the unique environment of Decision Support Systems (DSS). 

Press any key to continue! 


Figure A.1 


The ICEM model is actually three models in one. The 
COCOMO Intermediate model has been automated for all modes 
of operation including organic, semidetached and embedded 
modes. The second model specifically tailors the COCOMO 
semidetached mode for the DSS environment. The third model 
tailors the Function Point model for the DSS environment. 

Press any key to begin the consultation. 



Figure A.2 
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Would your like to retrieve a previously saved file? 

YES NO 

Which of the following models would you like to select? 

COCOMO = Regular COCOMO 

DSSCOC = COCOMO Tailored for DSS environment 

DSSFP = Function Point model tailored for DSS environment 

COCOMO DSSCOC DSSFP 


This model is designed to be used as a cost 
estimation tool for Decision Support System projects that 
meet the requirements as specified by the Organic mode of 
the Intermediate COCOMO model. The following 
characteristics apply to projects which meet these 
requirements: 

a. Generally stable development environment. 

b. Minimal need for innovation in architectures of 
algorithms. 

c. Relatively small size. 

d. Relatively low premium on early completion of 
the project. 

e. Software project range usually not greater than 
50 KDSI. 

f. Loose coupling with external systems. 


This calibrated model estimates the development time 
and cost (in man-months) of a software project based on 
inputs of estimated number of thousand of delivered source 
instructions (KDSI), and values for 15 cost drivers. 

Nominal values of 1.0 may be entered for unknown cost driver 
information. 



What is your best estimation on the number of thousands 
of delivered source instructions your program will have? 

5 


You have entered 5 kdsi. 


(Press enter to continue) 


Cost drivers are factors to consider in developing a 
model for estimating the cost of a software project. The 
drivers are grouped into four categories: software product 
attributes, computer attributes, personnel attributes, and 
project attributes. 


Press enter to continue 


The product attributes are: 

RELY - required software reliability, 
DATA - data base size, and 
CPLX - product complexity. 

Press enter to continue 
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The computer attributes are: 


TIME - execution time constraint, 

STOR - main storage constraint, 

VIRT - virtual machine volatility, and 
TURN - computer turnaround time. 

Press enter to continue 


The personnel attributes are: 

ACAP - analyst capability, 

AEXP - applications experience, 

PCAP - programmer capability, 

VEXP - virtual machine experience, and 
LEXP - programming language experience 
Press enter to continue 


The project attributes are: 

MODP - modern programming practices, 

TOOL - use of software tools 

SCED - required development schedule. 

Press enter to continue 
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Each of these cost driver attributes determines a 
multiplying factor which estimates the effect of the 
attribute on software development. These multipliers 
are applied to a nominal COCOMO development effort estimate 
to obtain a refined estimate of software development effort. 


Press enter to continue 


Ratings RELY: VLOW - effect, slight inconvenience. 

LOW - easily recoverable losses. 

NOM - moderate, recoverable losses. 

HIGH - high financial loss. 

VHI AND XTRAHI - risk to human life. 

Select a rating for required software reliability (RELY). 
VLOW LOW NOM 

HI VHI XTRAHI 


Ratings DATA: VLOW and LOW - DB bytes/ prog. DSI < 10. 

NOM - 10 <= D/P <= 100. 

HIGH - 100 <= D/P <=1000. 

XTRAHI - D/P >= 1000. 

Select a rating for data base size (DATA). 

VLOW LOW NOM 

HI VHI XTRAHI 


Ratings CPLX: VLOW - straightline code. 

LOW - straightforward nesting of structured 
programming 

NOM - mostly simple nesting. 

HIGH - highly nested SP operators. 

VHI - reentrant and recursive coding. 

XTRAHI-microcode level control. 

Select a rating for product complexity (CPLX). 

VLOW LOW NOM 

HI VHI XTRAHI 
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Ratings TIME: VLOW, LOW - 50 % use of available execution time. 

NOM - 50 % use of available execution time. 
HIGH 70 %. 

VHI - 85 %. 

XTRAHI - 95 %. 

Select a rating for execution time constraint (TIME). 

VLOW LOW NOM 

HI VHI XTRAHI 


Ratings STOR: VLOW, LOW, NOM- 50 % use of available storage. 
HIGH - 70 %. 

VHI - 85 %. 

XTRAHI - 95 %. 

Select a rating for main storage constraint (STOR). 

VLOW LOW NOM 

HI VHI XTRAHI 


Ratings VIRT: VLOW - major change every 12 months, minor: 1 month 
LOW - major change every 12 months, minor: 1 month 
NOM - major: 6 months minor: 2 weeks 
HIGH - major: 2 months minor: 1 week. 

VHI, XTRAHI - major: 2 weeks minor: 2 days. 

Select a rating for virtual machine volatility (VIRT). 

VLOW ’ LOW NOM 

HI VHI XTRAHI 


Ratings TURI': VLOW, LOVJ - interactive. 

NOM - average turnaround < 4 hour*- . 

HIGH - 4-12 hours. 

VHI,XTRAHI - >12 hours 

Select a rating for computer turnaround time (TURN). 

VLOW LOW NOM 

HI VHI XTRAHI 


Ratings ACAP: VLOW - 15th percentile. 

LOW - 35th. 

NOM - 55th. 

HIGH - 75th. 

VHI, XTRAHI - 90th. 

Select a rating for analyst capability (ACAP). 
VLOW LOW 

HI VHI 


NOM 

XTRAHI 




Ratings AEXP: VLOW - <= 4 months experience. 

LOW - 1 year. 

NOM - 3 years. 

HIGH - 6 years. 

VHI,XTRAHI - 12 years. 

Select a rating for applications experience (AEXP). 

VLOW LOW NOM 

HI VHI XTRAHI 

Ratings PCAP: VLOW - 15th percentile. 

LOW - 35th. 

NOM - 55th. 

HIGH - 75th. 

VHI, XTRAHI - 90th. 

Select a rating for programmer capability (PCAP). 

VLOW LOW NOM 

HI VHI XTRAHI 


Ratings VEXP: VLOW - <= 1 month. 

LOW - 4 months. 

NOM - 1 year. 

HIGH, VHI, XTRAHI - 3 years. 

Select a rating for virtual machine experience (VEXi). 
VLOW LOW NOM 

HI VHI XTRAHI 


Ratings LEXP: VLOW - 1 month experience. 

LOW - 4 months. 

NOM - 1 year. 

HIGH, VHI, XTRAHI - 3 years. 

Select a rating for programming language experience (LEXP). 
VLOW LOW NOM 

HI VHI XTRAHI 


Ratings MODP: VLOW - no use. 

LOW - beginning use. 

NOM - some use. 

HIGH - general use. 

VHI, XTRAHI - routine use. 

Select a rating for modern programming practices (MODP). 
VLOW LOW NOM 

HI VHI XTRAHI 
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Ratings TOOL: VLOW - basic microprocessor tools. 

LOW - basic mini tools. 

NOM - basic midi/maxi tools 

HIGH - strong maxi programming, test tools. 

VHI, XTRAHI - add requirements, design, management, 
documentation tools. 

Select a rating for use of software tools (TOOL). 

VLOW LOW NOM 

HI VHI XTRAHI 

Ratings SCED: VLOW - 75 % of nominal. 

LOW - 85 %. 

NOM - 100 %. 

HIGH - 130 %. 

VHI, XTRAHI - 160 %. 

Select a rating for required development schedule (SCED). 

VLOW LOW NOM 

HI VHI XTRAHI 


You have chosen the DSS COCOMO model! 


(Saving Data to Spreadsheet, Please Wait...) 


VALUES SAVED! 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS) 
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! INTERMEDIATE COCOMO 

1 

ORGANIC 

MODE 

EFFORT/SCHEDULE 

i KDSI 

= 

5.00 

COST DRIVERS 

** CTRL FI ** TO VIEW 






DEFINITIONS 

i MM 


17.34 

RELY 

.75 


1 

1 



DATA 

.94 

** CTRL F2 ** TO VIEW 

TDEV 

= 

7.39 

CPLX 

1.00 

COST DRIVER RATINGS 

i 



TIME 

1.00 


EAF 

= 

1.11 

STOR 

1.00 

** CTRL F3 ** TO SAVE 

1 



VIRT 

.87 

RESULTS TO: DSSCOC.WKS 

1 - 



TURN 

1.00 

AND EXIT SPREADSHEET 




ACAP 

1.19 


j MMadj 

= 

19.24 

AEXP 

1.29 

** YOU MAY CHANGE KDSI 




PCAP 

1.00 

AND COST DRIVER VALUES 

: #PERS 

z= 

2.60 

VEXP 

1.21 

AS NEEDED 




LEXP 

1.07 


PROD 

= 

259.92 

MODP 

.91 

******************** 

1 



TOOL 

1.00 

* For DSS projects * 

1 



SCED 

1.00 

******************** 


Figure A.3 


COST DRIVERS 



VLOW 

LOW 

NOM 

HIGH 

VHI 

XtraHI 


RELY 

.75 

. 88 

1.00 

1.15 

1.40 

1.40 


DATA 

.94 

.94 

1.00 

1.08 

1.16 

1.16 


CPLX 

.70 

. 85 

1.00 

1.15 

1.30 

1.65 


TIME 

1.00 

1.00 

1.00 

1.11 

1.30 

1.66 

** (CTRL F5) TO 

STOR 

1.00 

1.00 

1.00 

1.06 

1.21 

1.56 

RETURN TO MAIN 

VIRT 

.87 

. 87 

1.00 

1.15 

1.30 

1.30 

SPREADSHEET 

TURN 

. 87 

. 87 

1.00 

1,07 

1.15 

1.15 


ACAP 

1.46 

1.19 

1.00 

.86 

.71 

.71 


AEXP 

1.29 

1.13 

1.00 

1.00 

.91 

.82 


PCAP 

1.42 

1.17 

1.00 

.86 

.70 

.70 


VEXP 

1.21 

1.10 

1.00 

.90 

.90 

.90 


LEXP 

1.14 

1.07 

1.00 

.95 

. 95 

. 95 


MODP 

1.24 

1.10 

1.00 

.91 

.82 

.82 


TOOL 

1.24 

1.10 

1.00 

.91 

.83 

.83 


SCED 

1.23 

1.08 

1.00 

1.04 

1.10 

1.10 



Figure A.4 
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FUNCTION POINT MODEL EFFORT/SCHEDULE 


FUNCTION 


Value ' 

CPLX 

COUNT : 

RATINGS 

** CTRL FI ** TO 





1 



VIEW COMPLEXITY 

Inputs 

= 

25 

3 

75 1 

Ql. 

1.00 

RATINGS 

Outputs 

= 

7 

5 

35 i 

Q2. 

3.00 


Inquiries 

= 

5 

3 

15 i 

Q3. 

2.00 

** CTRL F3 ** TO 

Files 

= 

6 

7 

42 1 

Q4. 

4.00 

SAVE RESULTS TO: 

Interfaces 

= 

3 

5 

15 : 

Q5. 

2.00 

DSSFP.WKS AND EXIT 

Total 

= 



182 

Q6. 

3.00 

SPREADSHEET 


— 



-- 

Q7. 

2.00 






i 

Q8. 

1.00 

** YOU MAY CHANGE 

RATINGS 

= 

38.00 



Q9. 

4.00 

FUNCTION VALUES 






QIO. 

2.00 

AND COMPLEXITY 

FP 

= 

187.46 



Qll. 

3.00 

RATINGS AS NEEDED 






Q12. 

4.00 


MM 

= 

2.50 


! 

Q13. 

2.00 







Q14. 

5.00 



Figure A.5 
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APPENDIX B 


SOURCE CODE 


The source code for the two knowledge bases (ICEMl.KBS) and 
(ICEM2.KBS) is displayed in sections A and B respectively. 

A. (ICEMl.KBS) FILE 
RUNTIME; 

EXECUTE; 

BKCOLOR=3; 

ACTIONS 

WOPEN 1,3,5,13,70,1 
ACTIVE 1 
color = 15 
DISPLAY " 

Welcome to the ICEM model! 


The ICEM model is an integrated cost estimation model 
which uses an expert system to automate the Intermediate 
constructive Cost Estimation MOdel (COCOMO), developed by 
Barry W. Boehm and the Function Point Model, developed by 
Allen Albrecht. Both of these models have been tailored to 
the unique environment of Decision Support Systems (DSS). 

Press any key to continue 

WCLOSE 1 

WOPEN 1,3,5,12.70,1 
ACTIVE 1 
color = 15 
DISPLAY " 

The ICEM model is actually three models in one. The 
COCOMO Intermediate model has been automated for all modes 
of operation including organic, semidetached and embedded 
modes. The second model specifically tailors the COCOMO 
semidetached mode for the DSS environment. The third model 
tailors the Function Point model for the DSS environment. 

Press any key to begin the consultation.-" 

WCLOSE 1 
color = 0 
CLS 

FIND continue 
review = YES 

WHILETRUE model = COCOMO and review = YES THEN 
CLS 

WOPEN 1,3,5,12,70,1 








ACTIVE 1 

color = 15 

DISPLAY " 

The Intermediate COCOMO model uses 15 cost drivers 
applied to various attributes of a software project, 
the estimated number of thousand of delivered source 
instructions (KDSI), and the development mode to estimate 
the development time and cost of a software development 
project. 

— n 

CLS 

DISPLAY " 

The development mode of the project is determined by 
its size and complexity. The development mode may be 
considered either ORGANIC, SEMIDETACHED, or EMBEDDED. 

A listing of criteria for each mode follows. Determine 
the mode that best identifies your software project. 

_ II 

CLS 

DISPLAY " 

1. ORGANIC 

a. Generally stable development environment. 

b. Minimal need for innovation in architectures of 
algorithms. 

c. Relatively small size. 

d. Relatively low premium on early completion of 
the project. 

e. Software project range usually not greater than 
50 KDSI. 

f. Loose coupling with external systems. 


CLS 

DISPLAY " 

2. SEMIDETACHED 

a. Mixture of organic and embedded characteristics. 

b. Intermediate level of experience with related 
systems. 

c. Wide mix of experienced and inexperienced people. 

d. Some experience with aspects of system under 
development. 

e. Software project range usually not greater than 
300 KDSI. 

... II 

CLS 

DISPLAY " 
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EMBEDDED 


3 . 


a. Much innovation required. 

b. Integral part of some larger system with 
inflexibility. 

c. Interface requirements. 

d. High required reliability. 

e. Development within tight time and cost constraints. 

WCLOSE 1 
color = 0 
CLS 

RESET review 
FIND review 

END 

review = YES 

WHILETRUE model = DSSCOC and review = YES THEN 
CLS 

WOPEN 1,1,5,20,70,1 
ACTIVE 1 
color = 15 
DISPLAY " 

This model is designed to be used as a cost 
estimation tool for Decision Support System projects that 
meet the requirements as specified by the Organic mode of 
the Intermediate COCOMO model. The following 
characteristics apply to projects which meet these 
requirements: 

a. Generally stable development environment. 

b. Minimal need for innovation in architectures of 
algorithms. 

c. Relatively small size. 

d. Relatively low premium on early completion of 
the project. 

e. Software project range usually not greater than 
50 KDSI. 

f. Loose coupling with external systems. 

—11 

WCLOSE 1 

WOPEN 1,3,5,12,70,1 
ACTIVE 1 
color = 15 
CLS 

DISPLAY " 

This calibrated model estimates the development time 
and cost (in man-months) of a software project based on 
inputs of estimated number of thousand of delivered scource 
instructions (KDSI), and values for 15 cost drivers. 
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Nominal values of 1.0 may be entered for unknown cost driver 
information. 

— II 

review = NO 
WCLOSE 1 
color = 0 

END 

review = YES 

WHILETRUE model = DSSFP and review = YES THEN 
WOPEN 1,3,5,12,70,1 
ACTIVE 1 
color = 15 
CLS 

DISPLAY " 

The Function Point model makes effort estimates based 
on Allen Albrecht's function point sizing metric, 
metric based on five project factors which are measured by 
the user. These include: 

1. Inputs 

2. Outputs 

3. Inquiries 

4. Files 

5. Interfaces 

~ II 

WCLOSE 1 

WOPEN 1,3,5,17,70,1 
ACTIVE 1 
color = 15 
CLS 

DISPLAY " . 

Due to difficulties in ex-post data gathering it 
was not possible to properly calibrate the model for 
the DSS environment. However, the framework for the 
model has been completed and the model has automated 
the process of determining the function point sizing 
metric. In order for the model to be able to make 
effort estimates on projects it must be calibrated to 
the users's environment. The method for calculating 
calibration coefficients is explained in Chapter V, 
section D of the thesis. Once the coefficients have 
been calculated they should be added to the (MM) effort 
equation located in cell B18 of the DSSFP.WKS 
spreadsheet. 


Press any key to begin-" 

review = NO 
WCLOSE 1 
color = 0 
CLS 

END 

FIND finish; 
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I************************* START RULES BLOCK ********************* 


RULE 1 
IF 

THEN 


RULE 2 
IF 

THEN 

RULE 3 
IF 

THEN 


retreive = YES and file <> UNKOWN 
Display " 

ABOUT TO VIEW SAVED SPREADSHEET FILE" 
COLOR =30 
DISPLAY" 


(PRESS ENTER TO CONTINUE!)-" 
COLOR = 0 

SAVEFACTS fixvalue 
continue = NO; 


retreive = NO and Model <> UNKOWN 
continue = YES; 


continue=YES and inodel=COCOMO and inode=ORGANIC and 
kdsi=OK and LASTDRIVE=DONE 
DISPLAY " 

You have chosen the (MODEL) (MODE) mode" 
COLOR =30 
DISPLAY" 


(SAVING DATA TO SPREADSHEET, PLEASE WAIT....) 

tt 

PWKS kdsi_value, C4, c;\vpexp\organic 
PWKS rrating, G6, c:\vpexp\organic 
PWKS drating, G7, c:\vpexp\organic 
PWKS crating, G8, c;\vpexp\organic 
PWKS trating, G9, c;\vpexp\organic 
PWKS srating, GIO, c:\vpexp\organic 
PWKS vrating, Gil, c:\vpexp\organic 
PWKS turrating, G12, c:\vpexp\organic 
PWKS aerating, G13, c:\vpexp\organic 
PWKS aerating, G14, c:\vpexp\organic 
PWKS prating, G15, c:\vpexp\organic 
PWKS verating, G16, c:\vpexp\organic 
PWKS Irating, G17, c:\vpexp\organic 
PWKS mrating, G18, c:\vpexp\organic 
PWKS torating, G19, c:\vpexp\organic 
PWKS scrating, G20, c;\vpexp\organic 

RESET ALL 
retreive = NO 
mode = ORGANIC 
SAVEFACTS fixvalue 
finish = DONE; 
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RULE 4 
IF 

THEN 


RULE 5 
IF 

THEN 


continue=YES and inodel=COCOMO and inode=SEMIDETACHED and 
kdsi=OK and LASTDRIVE = DONE 
DISPLAY " 

You have chosen the {MODEL) (MODE) mode" 

COLOR =30 
DISPLAY" 


(SAVING DATA TO SPREADSHEET, PLEASE WAIT....) 

tl 

PWKS )cdsi_value, C4, c:\vpexp\semidet 
PWKS rrating, G6, c:\vpexp\semidet 
PWKS drating, G7, c:\vpexp\semidet 
PWKS crating, G8, c:\vpexp\semidet 
PWKS trating, G9, c:\vpexp\semidet 
PWKS srating, GIO, c:\vpexp\semidet 
PWKS vrating, Gll, c:\vpexp\semidet 
PWKS turrating, G12, c:\vpexp\semidet 
PWKS aerating, G13, c:\vpexp\semidet 
PWKS aerating, G14, c:\vpexp\semidet 
PWKS prating, G15, c:\vpexp\semidet 
PWKS verating, G16, c:\vpexp\semidet 
PWKS Irating, G17, c:\vpexp\semidet 
PWKS mrating, G18, c:\vpexp\semidet 
PWKS torating, G19, c:\vpexp\semidet 
PWKS scrating, G20, c:\vpexp\semidet 

RESET ALL 
retreive = NO 
mode = SEMIDETACHED 
SAVEFACTS fixvalue 
finish = DONE; 


continue=Yes and model=COCOMO and mode=EMBEDDED and 
kdsi=OK and LASTDRIVE = DONE 
DISPLAY " 

You have chosen the (MODEL) (MODE) mode" 

COLOR =30 
DISPLAY" 


(SAVING DATA TO SPREADSHEET, PLEASE WAIT....) 

tl 


PWKS 

PWKS 

PWKS 

PWKS 

PWKS 

PWKS 


kdsi_value, 
rrating, G6, 
drating, G7, 
crating, G8, 
trating, G9, 
srating, GIO 


C4, c:\vpexp\organic 
c:\vpexp\organic 
c:\vpexp\organic 
c:\vpexp\organic 
c:\vpexp\organic 
, c:\vpexp\organic 
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RULE 6 
IF 

THEN 


PWKS vrating, Gil, c:\vpexp\organic 
PWKS turrating, G12, c:\vpexp\organic 
PWKS aerating, G13, c:\vpexp\organic 
PWKS aerating, G14, c:\vpexp\organic 
PWKS prating, G15, c:\vpexp\organic 
PWKS verating, G16, c:\vpexp\organic 
PWKS Irating, G17, c:\vpexp\organic 
PWKS mrating, G18, c:\vpexp\organic 
PWKS torating, G19, c:\vpexp\organic 
PWKS scrating, G20, c:\vpexp\organic 

RESET ALL 
retreive = NO 
mode - EMBEDDED 
SAVEFACTS fixvalue 
finish = DONE; 


continue = YES and model = DSSCOC and kdsi=OK and 
LASTDRIVE = DONE 
DISPLAY " 

You have chosen the DSS COCOMO model" 
COLOR =30 
DISPLAY" 


(SAVING DATA TO SPREADSHEET, PLEASE WAIT....) 

u 

PWKS kdsi_value, C4, c:\vpexp\dsscoc 
PWKS rrating, G6, c:\vpexp\dsscoc 
PWKS drating, G7, c:\vpexp\dsscoc 
PWKS crating, G8, c:\vpexp\dsscoc 
PWKS trating, G9, c:\vpexp\dsscoc 
PWKS srating, GIO, c;\vpexp\dsscoc 
PWKS vrating, Gil, c;\vpexp\dsscoc 
PWKS turrating, G12, c:\vpexp\dsscoc 
PWKS aerating, G13, c:\vpexp\dsscoc 
PWKS aerating, G14, c:\vpexp\dsscoc 
PWKS prating, G15, c:\vpexp\dsscoc 
PWKS verating, G16, c:\vpexp\dsscoc 
PWKS Irating, G17, c:\vpexp\dsscoc 
PWKS mrating, G18, c:\vpexp\dsscoc 
PWKS torating, G19, c:\vpexp\dsscoc 
PWKS scrating, G20, c;\vpexp\dsscoc 

RESET ALL 
retreive = NO 
model = dsscoc 
SAVEFACTS fixvalue 
finish = DONE; 
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RULE 7 

IF continue = YES and model = DSSFP 

THEN FIND inputs 

CLS 

DISPLAY " 

Classifying inputs for complexity depends on two things: 
the number of files referenced or accessed, and the number of 
data items (fields or specific variables) referenced. Use the 
following chart for classifying inputs: 

Press any key to view chart! 

~ II 


CLS 

DISPLAY " 



1-4 data items 
referenced 

5-15 


16 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(3) 

Simple 

(3) 

Average 

(4) 

2 files 
referenced 

Simple 

(3) 

Average 

(4) 

Complex 

(6) 

3 or more 
files ref. 

Average 

(4) 

Complex 

(6) 

Complex 

(6) 


It 


FIND input_cplx 

CLS 

FIND outputs 

CLS 

FIND output_cplx 

CLS 

FIND inquiries 

CLS 

DISPLAY " 

Classifying inquiries consists of two parts: 
classifying the inputs and classifying the outputs. The 
same charts are used for inputs and outputs as before. The 
only difference is that while a stand alone input actually 
updates the data store, an inquiry only directs the search 
and never updates. Use the following chart to classify the 
input inquiries: 

Press any key to view chart! 

~ II 

CLS 

DISPLAY " 
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Input part: 

1-4 data items 
referenced 

5-15 


16 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(3) 

Simple 

(3) 

Average 

(4) 

2 files 
referenced 

Simple 

(3) 

Average 

(4) 

Complex 

(6) 

3 or more 
files ref. 

Average 

(4) 

Complex 

(6) 

Complex 

(6) 


II 

FIND in_inquir_cplx 

CLS 

FIND out_inquir_cplx 

CLS 

FIND inquir_cplx 

CLS 

FIND files 

CLS 

DISPLAY " 

Classifying files is also a two step process which 
involves cross referencing the number of data items actually 
required by the application with the number of record formats 
within the file or the number of logical relationships in 
which the file participates are counted. Use the following 
chart to determine the file complexity factor: 

Press any key to view chart! 

~ 11 

CLS 

DISPLAY " 


1-19 data 20-50 51 or more 

items ref. data items 


1 logical record Simple (7) Simple (7) Average (10) 
format/relationship 


2-5 logical Simple (7) Average (10) Complex (15) 

record format/ 

relationships 

6 or more Ave. (10) Complex (15) Complex (15) 

logical record 

format/relationships 


tt 

FIND file_cplx 
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CLS 

FIND interfaces 
CLS 

DISPLAY " 

The classification scheme for interfaces is similar to the 
one used for files. Use the following chart to determine the 
interface complexity factor: 


Press 

CLS 

DISPLAY " 

any key to 

view chart 

1 




1-19 data 
items ref. 

20-50 


51 or more 
data items 

1 logical record 
format/relationship 

Simple (7) 

Simple 

(7) 

Average 

(10) 

2-5 logical 
record format/ 
relationships 

Simple (7) 

Average 

(10) 

Complex 

(15) 

6 or more 
logical record 
format/relationships 

Ave. (10) 

Complex 

(15) 

Complex 

(15) 


It 


FIND inter_cplx 
CLS 

FIND Q1 
CLS 

FIND Q2 
CLS 

FIND Q3 
CLS 

FIND Q4 
CLS 

FIND Q5 
CLS 

FIND Q6 
CLS 

FIND Q7 
CLS 

FIND Q8 
CLS 

FIND Q9 
CLS 

FIND QIO 
CLS 

FIND Qll 
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CLS 

FIND Q12 
CLS 

FIND Q13 
CLS 

FIND Q14 
CLS 

DISPLAY " 

You have chosen the DSS Function Point model" 
COLOR =30 
DISPLAY" 


(SAVING DATA TO SPREADSHEET, PLEASE WAIT-...) 

II 

PWKS inputs, B6, c:\vpexp\dssfp 
PWKS outputs, B7, c:\vpexp\dssfp 
PWKS inquiries, B8, c:\vpexp\dssfp 
PWKS files, B9, c:\vpexp\dssfp 
PWKS interfaces, BIO, c:\vpexp\dssfp 
PWKS input_cplx, D6, c:\vpexp\dssfp 
PWKS output_cplx, D7, c:\vpexp\dssfp 
PWKS inquir_cplx, D8, c:\vpexp\dssfp 
PWKS file_cplx, D9, c:\vpexp\dssfp 
PWKS inter_cplx, DIO, c:\vpexp\dssfp 


PWKS Ql, H6, 
PWKS Q2, H7, 
PWKS Q3, H8, 
PWKS Q4, H9, 
PWKS Q5, HIO, 
PWKS Q6, Hll, 
PWKS Q7, H12, 
PWKS Q8, H13, 
PWKS Q9, H14, 
PWKS QIO, H15, 
PWKS Qll, H16, 
PWKS Q12, H17, 
PWKS Q13, H18, 
PWKS Q14, H19, 


c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c;\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c:\vpexp\dssfp 
c;\vpexp\dssfp 
c:\vpexp\dssfp 
c;\vpexp\dssfp 


RESET ALL 
retreive = NO 
model = DSSFP 
SAVEFACTS fixvalue 
finish = DONE; 
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RULE 8 
IF 

THEN 

RULE 9 
IF 

THEN 


RULE 10 
IF 

THEN 

RULE 11 
IF 

THEN 

RULE 12 
IF 

THEN 

RULE 13 
IF 

THEN 


RULE 14 
IF 

THEN 


out_inquir_cplx = 7 
inquir_cplx = 7; 


out_inquir_cplx = 5 and in_inquir_cplx = 6 
inquir_cplx = 6; 


out_inquir_cplx = 5 and in_inquir_cplx < 6 
inquir_cplx = 5; 


out_inquir_cplx = 4 and ininquir_cplx = 6 
inquir_cplx = 6; 


out_inquir_cplx = 4 and in_inquir_cplx < 6 
inquir_cplx = 4; 


kdsi_value<=0 

WHILETRUE kdsi_value<=0 THEN 
CLS 

COLOR =30 
DISPLAY" 

You must enter a value greater than 0 
You have entered {kdsi_value} kdsi. 

II 

COLOR = 0 
RESET kdsi_value 
FIND kdsi_value 

END 

DISPLAY" 

You have entered {kdsi_value) kdsi." 
COLOR =30 
DISPLAY" 

(Press Enter to continue) 

— II 

COLOR = 0 
kdsi = OK; 


kdsi_value > 0 
DISPLAY" 

You have entered (kdsivalue) kdsi." 
COLOR =30 
DISPLAY" 
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(Press enter to continue) 

•> 

COLOR = 0 



kdsi = OK; 

RULE 15 

IF 

kdsi = ok 

THEN 

CLS 


WOPEN 2,3,5,16,70,1 
ACTIVE 2 
COLOR =15 
DISPLAY" 

Cost drivers are factors to consider in developing a 
model for estimating the cost of a software project. The 
drivers are grouped into four categories: software product 
attributes, computer attributes, personnel attributes, and 
project attributes. 


Press enter to continue-" 

CLS 

DISPLAY" 

The product attributes are: 

RELY - required software re3iability, 
DATA - data base size, and 
CPLX - product complexity. 


Press enter to continue-" 

CLS 

DISPLAY" 

The computer attributes are: 

TIME - execution time constraint, 

STOR - main storage constraint, 

VIRT - virtual machine volatility, and 
TURN - computer turnaround time. 
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Press enter to continue-" 


CLS 

DISPLAY" 

The personnel attributes are: 

ACAP - analyst capability, 

AEXP - applications experience, 

PCAP - programmer capability, 

VEXP - virtual machine experience, and 
LtXP - programming language experience. 

Press enter to continue-" 


CLS 

DISPLAY" 

The project attributes are: 

MODP - modern programming practices, 

TOOL - use of software tools 

SCED - required development schedule. 


Press enter to continue-" 


CLS 

DISPLAY " 


Each of these cost driver attributes determines a 
multiplying factor which estimates the effect of the 
attribute on software development. These multipliers 
are applied to a nomial COCOMO development effort estimate 
to obtain a refined estimate of software development effort. 


Press enter to continue-" 

WCLOSE 2 
COLOR = 0 
CLS 

SLOW = DONE; 

RULE 16 

IF SHOW = DONE and RELY = VLOW and driver2 = done 
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THEN RRATING = .75 

lastdrive = DONE; 

RULE 17 

IF SHOW = DONE and RELY = LOW and driver2 = done 

THEN RRATING = .88 

LASTDRIVE = DONE; 

RULE 18 

IF SHOW = DONE and RELY = NOM and driver2 = done 

THEN RRATING = 1.00 

LASTDRIVE = DONE; 

RULE 19 

IF SHOW = DONE and RELY = VHI and driver2 = done 

THEN RRATING = 1.40 

LASTDRIVE = DONE; 

RULE 20 

IF SHOVv = DONE and RELY = XTRAHI and driver2 = done 

THEN RRATING = 1.40 

LASTDRIVE = DONE; 

RULE 21 

IF SHOW = DONE and DATA = VLOW AND DRIVERS = DONE 

THEN DRATING = .94 

DRIVER2 = DONE; 

RULE 22 

IF DATA = LOW AND DRIVERS = DONE 

THEN DRATING = .94 

DRIVERS = DONE; 

RULE 2S 

IF DATA = NOM AND DRIVERS = DONE 

THEN DRATING = 1.00 

DRIVERS = DONE; 

RULE 24 

IF DATA = HI AND DRIVERS = DONE 

THEN DRATING = 1.08 

DRIVERS = DONE; 

RULE 25 

IF DATA = VHI AND DRIVERS = DONE 

THEN DRATING = 1.16 

DRIVERS = DONE; 

RULE 26 

IF DATA = XTRAHI AND DRIVERS = DONE 
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THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 


DRATING =1.16 
DRIVER2 = DONE; 


27 

CPLX = VLOW AND DRIVER4 = DONE 
CRATING = .70 
DRIVERS = DONE; 

28 

CPLX = LOW AND DRIVER4 = DONE 
CRATING = .85 
DRIVERS = DONE; 

29 

CPLX = NOM AND DRIVER4 = DONE 
CRATING = 1.00 
DRIVERS = DONE; 

50 

CPLX = HI AND DRIVER4 = DONE 
CRATING =1.15 
DRIVERS = DONE; 

51 

CPLX = VHI AND DRIVER4 = DONE 
CRATING = l.SO 
DRIVERS = DONE; 

52 

CPLX = XTRAHI AND DRIVER4 = DONE 
CRATING =1.65 
DRIVERS = DONE; 

53 

TIME = VLOW AND DRIVERS = DONE 
TRATING = 1.00 
DRIVER4 = DONE; 

34 

TIME = LOW AND DRIVERS = DONE 
TRATING = 1.00 
DRIVER4 = DONE; 

35 

TIME = NOM AND DRIVERS = DONE 
TRATING =1.00 
DRIVER4 = DONE; 

36 

TIME = HI AND DRIVERS = DONE 
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THEN 


TRATING 

DRIVER4 


1.11 

DONE ; 


RULE 

IF 

THEN 

37 

TIME = VHI AND DRIVERS = DONE 
TRATING = 1.30 

DRIVER4 = DONE; 

RULE 

IF 

THEN 

38 

TIME = XTRAHI AND DRIVERS = DONE 
TRATING =1.66 

DRIVER4 = DONE; 

RULE 

IF 

THEN 

39 

STOR = VLOW AND DRIVER6 = DONE 
SEATING = 1.00 

DRIVERS = DONE; 

RULE 

IF 

THEN 

40 

STOR = LOW AND DRIVER6 = DONE 
SEATING = 1.00 

DRIVERS = DONE; 

RULE 

IF 

THEN 

41 

STOR = NOM AND DRIVER6 = DONE 
SEATING = 1.00 

DRIVERS = DONE; 

RULE 

IF 

THEN 

42 

STOR = HI AND DRIVERS = DONE 
SEATING = 1.06 

DRIVERS = DONE; 

RULE 

IF 

THEN 

43 

STOR = VHI AND DRIVERS = DONE 
SEATING = 1.21 

DRIVERS = DONE; 

RULE 

IF 

THEN 

44 

STOR = XTRAHI AND DRIVER6= DONE 
SEATING =1.56 

DRIVERS = DONE; 

RULE 

IF 

THEN 

45 

VIRT = VLOW AND DRIVER? = DONE 
VRATING = .87 

DRIVERS = DONE; 

RULE 

IF 

46 

VIRT = LOW AND DRIVER? = DONE 
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THEN 


VRATING = .87 

DRIVER6 = DONE; 

RULE 

IF 

THEN 

47 

VIRT = NOM AND DRIVER7 = DONE 
VRATING = 1.00 

DRIVERS = DONE; 

RULE 

IF 

THEN 

48 

VIRT = HI AND DRIVER7 = DONE 
VRATING = 1.15 

DRIVERS = DONE; 

RULE 

IF 

THEN 

49 

VIRT = VHI AND DRIVER7 = DONE 
VRATING = 1.30 

DRIVERS = DONE; 

RULE 

IF 

THEN 

50 

VIRT = XTRAHI AND DRIVER7 = DONE 
VRATING 1.3 0 

DRIVERS = DONE; 

RULE 

IF 

THEN 

51 

TURN = VLOW AND DRIVERS = DONE 
TURRATING = .87 

DRIVER7 = DONE; 

RULE 

IF 

THEN 

52 

TURN = LOW AND DRIVERS = DONE 
TURRATING = .87 

DRIVER7 = DONE; 

RULE 

IF 

THEN 

53 

TURN = NOM AND DRIVERS = DONE 
TURRATING = 1.00 

DRIVER7 = DONE; 

RULE 

IF 

THEN 

54 

TURN = HI AND DRIVERS = DONE 
TURRATING = 1.07 

DRIVER7 = DONE; 

RULE 

IF 

THEN 

55 

TURN = VHI AND DRIVERS = DONE 
TURRATING =1.15 

DRIVER7 = DONE; 

RULE 

IF 

5b 

TURN = XTRAHI AND DRIVERS = DONE 
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THEN 


TURRATING = 1.15 

DRIVER? = DONE; 


RULE 

IF 

THEN 

57 

ACAP = VLOW AND DRIVER9 = 
ACRATING = 1.46 

DRIVERS = DONE; 

DONE 

RULE 

IF 

THEN 

58 

ACAP = LOW AND DRIVER9 = 
ACRATING =1.19 

DRIVERS = DONE; 

DONE 

RULE 

IF 

THEN 

59 

ACAP = NOM AND DRIVER9 = 
ACRATING = 1.00 

DRIVERS = DONE; 

DONE 

RULE 

IF 

THEN 

60 

ACAP = HI AND DRIVER9 = DONE 
ACRATING = .86 

DRIVERS = DONE; 

RULE 

IF 

THEN 

61 

ACAP = VHI AND DRIVER9 = 
ACRATING = .71 

DRIVERS = DONE; 

DONE 

RULE 

IF 

THEN 

62 

ACAP = XTRAHI AND DRIVER9 
ACRATING = .71 
hdtverS = noNP; 

= DONE 

RULE 

IF 

THEN 

63 

AEXP = VLOW AND DRIVERIO 
AERATING = 1.29 

DRIVER9 = DONE; 

= DONE 

RULE 

IF 

THEN 

64 

AEXP = LOW AND DRIVERIO = 
AERATING = 1.13 

DRIVER9 = DONE; 

DONE 

RULE 

IF 

THEN 

65 

AEXP = NOM AND DRIVERIO = 
AERATING = 1.00 

DRIVER9 = DONE; 

DONE 


RULE 66 
IF 


AEXP 


HI AND DRIVERIO 


DONE 








THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN- 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 


AERATING = .91 
DRIVER9 = DONE; 


67 

AEXP = VHI AND DRIVERIO = DONE 
AERATING = .82 
DRIVER9 = DONE; 

68 

AEXP = XTRAHI AND DRIVERIO = DONE 
AERATING = .82 
DRIVER9 = DONE; 

69 

PCAP = VLOW AND DRIVERll = DONE 
PRATING = 1.42 
DRIVERIO = DONE; 

70 

PCAP = LOW AND DRIVERll = DONE 
PRATING = 1.17 
DRIVERIO = DONE; 

71 

PCAP = NOM AND DRIVERll = DONE 
PRATING = 1.00 
DRIVERIO = DONE; 

7 2 

PCAP = HI AND DRIVERll = DONE 
PRATING = .86 
DRIVER! , DONE; 

73 

PCAP = VHI AND DRIVERll = DONE 
PRATING = .70 
DRIVERIO = DONE; 

7 4 

PCAP = XTRAHI AND DRIVERll = DONE 
PRATING = .70 
DRIVERIO = DONE; 

75 

VEXP = VLOW AND DRIVER12 = DONE 
VERATING = 1.21 
DRIVERll = DONE; 

76 

VEXP = LOW AND DRIVER12 = DONE 
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THEN 


V/ERATING 

DRIVERll 


1.10 

DONE; 


RULE 

IF 

THEN 

77 

VEXP = NOM AND DR1VER12 
VERATING = 1.00 

DRIVERll = DONE; 

= DONE 

RULE 

IF 

THEN 

78 

VEXP = HI AND DRIVER12 = 
VERATING = .90 

DRIVERll = DONE; 

DONE 

RULE 

IF 

THEN 

79 

VEXP = VHI AND DRIVER12 
VERATING = .90 

DRIVERll = DONE; 

= DONE 

RULE 

IF 

THEN 

80 

VEXP = XTRAHI AND DRIVER12 = DONE 
VERATING = .90 

DRIVERll = DONE; 

RULE 

IF 

THEN 

81 

LEXP = VLOW AND DRIVER13 
LRATING =1.14 

DRIVER12 = DONE; 

= DONE 

RULE 

IF 

THEN 

82 

LEXP = LOW AND DRIVER13 
LRATING = 1.07 

DRIVER12 = DONE; 

= DONE 

RULE 

IF 

THEN 

83 

LEXP = NOM AND DRIVER13 
LRATING = 1.00 

DRIVER12 = DONE; 

= DONE 

RULE 

IF 

THEN 

84 

LEXP = HI AND DRIVER13 = 
LRATING = .95 

DRIVER12 = DONE; 

DONE 

RULE 

IF 

THEN 

85 

LEXP = VHI AND DRIVER13 
LRATING = .95 

DRIVER12 = DONE; 

= DONE 

RULE 

IF 

86 

LEXP = XTRAHI AND DRIVER13 = DONE 






THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 

THEN 


RULE 

IF 


LRATING = .95 
DRIVER12 = DONE; 


87 

MODP = VLOW AND DRIVER14 = DONE 
MRATING = 1.24 
DRIVER!3 = DONE; 

88 

MODP = LOW AND DRIVER14 = DONE 
MRATING = 1.10 
DRIVER13 = DONE; 

89 

MODP = NOM AND DRIVER14 = DONE 
MRATING = 1.00 
DRIVER13 = DONE; 

90 

MODP = HI AND DRIVER14 = DONE 
MRATING = .91 
DRIVER13 = DONE; 

91 

MODP = VHI AND DRIVER14 = DONE 
MRATING = .82 
DRIVER13 = DONE; 


MODP = XTRAHI AND DRIVER14 = DONE 
MRATING = .82 
DRIVER13 = DONE; 


93 

TOOL = VLOW AND DRIVER15 = DONE 
TORATING = 1.24 
DRIVER14 = DONE; 

94 

TOOL = LOW AND DRIVER15 = DONE 
TORATING = 1.10 
DRIVER14 = DONE; 


TOOL = NOM AND DRIVER15 = DONE 
TORATING = 1.00 
DRIVER14 = DONE; 


96 

TOOL = HI AND DRIVER15 = DONE 
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THEN 


TORATING 

DRIVER14 


.91 

DONE 


RULE 

IF 

THEN 

97 

TOOL = VHI AND DRIVER15 = DONE 
TORATING = .83 

DRIVER14 = DONE; 

RULE 

IF 

THEN 

98 

TOOL = XTRAHI AND DRIVER15 = DONE 
TORATING = .83 

DRIVER14 = DONE; 

RULE 

IF 

THEN 

99 

SCED = VLOW 

SCRATING = 1.23 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

100 

SCED = LOW 

SCRATING = 1.08 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

101 

SCED = NOM 

SCRATING =1.00 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

102 

SCED = HI 

SCRATING = 1.04 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

103 

SCED = VHI 

SCRATING = 1.10 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

104 

SCED = XTRAHI 

SCRATING = 1.10 

DRIVER15 = DONE; 

RULE 

IF 

THEN 

105 

retreive = YES 
finish = done; 


I************************ START QUESTIONS BLOCK *************** 

ASK retreive: "Would your like to retreive a previously saved 
file?"; 
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CHOICES retreive; YES, NO; 

ASK file: "Select the file to be retrieved 


ORGANIC 

SEMIDETACHED 

EMBEDDED 

DSSCOC 

DSSr'P 


COCOMO Organic Mode File 
COCOMO Semidetached Mode File 
COCOMO Embedded Mode File 
DSS COCOMO Semidetached Mode File 
DSS Function Point File 


M • 

I 

CHOICES file: ORGANIC, 


SEMIDETACHED, EMBEDDED, DSSCOC, DSSFP; 


ASK model: "Which of the following models would you like to select? 


COCOMO = Regular COCOMO 

DSSCOC = COCOMO Tailored for DSS environment 
DSSFP = Function Point model tailored for DSS 
environment 

n • 

/ 

CHOICES model: COCOMO, DSSCOC, DSSFP; 


ASK review: "Would you like to review the mode characteristics 
again?"; 

CHOICES review: YES, NO; 


ASK mode: "Which of the following modes best identifies your 
software project?"; 

CHOICES mode: ORGANIC, SEMIDETACHED, EMBEDDED; 

ASK kdsi_value: "What is your best estimation on the number of 
thousands of delivered source instructions your program will have? 

If • 

/ 


ASK RELY: " 

Ratings RELY: VLOW - effect, slight inconvenience. 

LOW - easily recoverable losses. 

NOM - moderate, recoverable losses. 

HIGH - high financial loss. 

VHI AND XTRAHI - risk to human life. 

Select a rating for required software reliability (RELY)."; 
CHOICES RELY: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK DATA: " 

Ratings DATA: VLOW and LOW - DB bytes/ prog. DSI < 10. 

NOM - 10 <= D/P <= 100. 

HIGH - 100 <= D/P <=1000. 

XTRAHI - D/P >= 1000. 

Select a rating for data base size (DATA)."; 

CHOICES DATA: VLOW, LOW, NOM, HI, VHI, XTRAHI; 
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ASK CPLX: " 

Ratings CPLX: VLOW - straightline code. 

LOW - straightforward nesting of structured 
programming (SP). 

NOM - mostly simple nesting. 

HIGH - highly nested SP operators. 

VHI - reentrant and recursive coding. 
XTRAHI-microcode level control. 

Select a rating for product complexity (CPLX)."; 


CHOICES 

CPLX: 

VLOW, 

LOW, : 

NOM, 

HI, VHI, 

XTRAHI; 

ASK TIME 

• II 






Ratings 

TIME: 

VLOW, 

LOW, 

NOM 

- 50 % 

use of available execution 

time. 


HIGH 

- 70 

%. 





VHI 

- 85 

%. 





XTRAHI 

- 95 

q, 

"o • 



Select a 

rating for 

execution 

time constraint (TIME)."; 

CHOICES 

TIME: 

VLOW, 

LOW, 

NOM, 

HI, VHI, 

XTRAHI ; 

ASK STOR 

: " 






Ratings 

STOR: 

VLOW, 

LOW, 

NOM- 

50 % use 

of available storage. 



HIGH 

- 70 

P, 

'P • 





VHI 

- 85 

%. 





XTRAHI 

- 95 

%. 




Select a rating for main storage constraint (STOR)."; 

CHOICES STOR: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK VIRT: " 

Ratings VIRT; VLOW, LOW - major change: 12 months, minor: 1 month. 

NOM - major change: 6 months, minor: 2 weeks 
HIGH - major: 2 months, minor: 1 week. 

VHI, XTRAHI - major: 2 weeks, minor: 2 days. 

Select a rating for virtual machine volatility (VIRT)."; 

CHOICES VIRT: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK TURN: " 

Ratings TURN: VLOW, LOW - interactive. 

NOM - average turnaround < 4 hours. 

HIGH - 4-12 hours. 

VHI,XTRAHI - >12 hours 

Select a rating for computer turnaround time (TURN)."; ♦ 

CHOICES TURN: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK ACAP: " 

Ratings ACAP: VLOW - 15th percentile. 
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LOW - 35th. 

NOM - 55th. 

HIGH - 75th. 

VHI, XTRAHI - 90th. 

Select a rating for analyst capability (ACAP)."; 

CHOICES ACAP: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK AEXP: " 

Ratings AEXP: VLOW - <= 4 months experience. 

LOW - 1 year. 

NOM - 3 years. 

HIGH - 6 years. 

VHI,XTRAHI - 12 years. 

Select a rating for applications experience (AEXP)."; 

CHOICES AEXP: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK PCAP: " 

Ratings PCAP: VLOW - 15th percentile. 

LOW - 35th. 

NOM - 55th. 

HIGH - 75th. 

VHI, XTRAHI - 90th. 

Select a rating for programmer capability (PCAP)."; 

CHOICES PCAP: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK VEXP: " 

Ratings VEXP: VLOW - <= 1 month. 

LOW - 4 months. 

NOM - 1 year. 

HIGH, VHI, XTRAHI - 3 years. 

Select a rating for virtual machine experience (VEXP)."; 
CHOICES VEXP: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK LEXP: " 

Ratings LEXP: VLOW - 1 month experience. 

LOW - 4 months. 

NOM - 1 year. 

HIGH, VHI, XTRAHI - 3 years. 

Select a rating for programming language experience (LEXP)." 
CHOICES LEXP: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK MODP: " 

Ratings MODP: VLOW - no use. 

LOW - beginning use. 

NOM - some use. 
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HIGH - general use. 

VHI, XTRAHI - routine use. 

Select a rating for modern programming practices (MODP)."; 

CHOICES MODP; VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK TOOL: " 

Ratings TOOL: VLOW - basic microprocessor tools. 

LOW ' jasic mini tools. 

NOM - basic midi/maxi tools 

HIGH - strong maxi programming, test tools. 

VHI, XTRAHI - add requirements, design, management, 
documentation tools. 

Select a rating for use of software tools (TOOL)."; 

CHOICES TOOL: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK SCED: " 

Ratings SCED: VLOW - 75 % of nominal. 

LOW - 85 %. 

NOM - 100 %. 

HIGH - 130 %. 

VHI, XTRAHI - 160 %. 

Select a rating for required development schedule (SCED)."; 
CHOICES SCED: VLOW, LOW, NOM, HI, VHI, XTRAHI; 

ASK inputs: " 

In measuring inputs each unique user data or control 
input that is performed by the user within the application 
in order to add, delete or update something should be counted. 

What is the number of inputs your program will have? 

II • 

r 

ASK input_cplx: " 

Select the input complexity factor: 

II • 

f 

CHOICES input_cplx: 3,4, 6; 


ASK outputs: " 

In measuring outputs, each unique user data or control 
output procedurally generated that leaves the application 
boundary should be counted. This includes reports, messages 
to the user, and outputs to other applications. 

What is the number of outputs your program will have? 

II • 

/ 

ASK output_cplx: " 
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Outputs are classified in a similar format as inputs. 
Use the following chart for classifying outputs: 



1-5 data items 
referenced 

6-19 

20 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(4) 

Simple (4) 

Average (5) 

2-3 files 

Simple 

(4) 

Average (5) 

Complex (7) 

4 or more 

Average 

(5) 

Complex (7) 

Cciiiplex (7) 


files ref. 


Select the output complexity factor: 

tl • 

/ 

CHOICES output_cplx: 4, 5, 7; 

ASK inquiries: " 

In measuring inquiries each unique input/output 
combination in which an on-line user-defined input causes 
and generates an immediate on-line output by the application 
should be counted. Many inquiries are simply requests for 
specific data from a database. 

What is the number of inquiries your program will have? 

II • 

t 

ASK in_inquir_cplx: " 

Select the input inquiries complexity factor: 

II • 

f 

CHOICES in_inquir_cplx: 3, 4, 6; 

ASK out_inquir_cpl.x: " 

Use the following chart to classify the output 
inquiries: 


Output Part: 

1-5 data items 
referenced 

6-19 


20 or more 
data items 

0 or 1 file(s) 
referenced 

Simple 

(4) 

Simple 

(4) 

Average 

(5) 

2-3 files 

Simple 

(4) 

Average 

(5) 

Complex 

(7) 

4 or more 
files ref. 

Average 

(5) 

Complex 

(7) 

Complex 

(7) 
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Select the output inquiries complexity factor: 

II • 

I 

CHOICES out_inquir_cplx: 4, 5, 7; 

ASK files: " 

Files are counted in the logical not physical sense. 
Therefore, you are not simply counting the number of physical 
files within your application. Rather, only files that contain 
data stored in logical groupings within the application are 
counted as files. These files perform data storage functions for 
the application. 

What is the number of files your program will have? 

II • 

9 

ASK filecplx: " 

Select the file complexity factor: 

II • 

9 

CHOICES file_cplx: 7, 10, 15; 


ASK interfaces: " 

Interfaces involve using data stored by another application 
but used by the current application. In measuring interfaces 
count every logical file that is sent to, shared with, or 
received from another application. 

What is the number of interfaces your program will have? 

II • 

9 

ASK inter_cplx: " 

Select the interface complexity factor: 

II • 

9 

CHOICES inter_cplx: 4, 5, 7; 

ASK Ql: " 

Answer each question based on a scale of 0 to 5 
where, 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Ql. Does the system require reliable backup and recovery? 
Select the appropriate rating scale: 

II. 

CHOICES Ql: 0, 1, 2, 3, 4, 5; 

ASK Q2: " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 
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Q2. Are data communications required? 

Select the appropriate rating scale: 

II • 

/ 

CHOICES Q2: 0, 1, 2, 3, 4, 5; 

ASK Q3: '• 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q3. Are data communications required? 

Select the appropriate rating scale: 

II • 

/ 

CHOICES Q3: 0, 1, 2, 3, 4, 5; 

ASK Q4: " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q4. Is performance critical? 

Select the appropriate rating scale: 

" > 

CHOICES Q4: 0, 1, 2, 3, 4, 5; 

ASK Q5: " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q5. Will the system run in an existing, heavily utilized 
operational environment? 

Select the appropriate rating scale: 

It • 

r 

CHOICES Q5: 0, 1, 2, 3, 4, 5; 

ASK Q6: " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q6. Does the system require on-line data entry? 
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Select the appropriate rating scale: 

II * 

t 

CHOICES Q6: 0, 1, 2, 3, 4, 5; 

ASK Q7; " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q7. Does the on-line data entry require the input 
transactions to be built over multiple screens 
or operations? 

Select the appropriate rating scale: 

ir • 
r 

CHOICES Q7: 0, 1, 2, 3, 4, 5; 

ASK Q8: " 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q8. Are the master files updated on-line? 

Select the appropriate rating scale: 

II » 

/ 

CHOICES Q8: 0, 1, 2, 3, 4, 5; 

ASK Q9: ” 

0 = no influence 3 = average 

1 = incidental 4 = significant 

2 = moderate 5 = essential 


Q9. Are the inputs, outputs, files, or inquiries complex? 

Select the appropriate rating scale: 

11 • 

r 

CHOICES Q9: 0, 1, 2, 3, 4, 5; 

ASK QIO: ” 

0 = no influence 3 = average 

1 = incidental 4 = significai.t 

2 = moderate 5 = essential 
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QIO. Is the internal processing complex? 


Select the appropriate rating scale: 

tl • 

r 

CHOICES QIO: 0, 1, 2, 3, 4, 5; 


ASK Qll: " 

0 = no influence 

1 = incidental 

2 = moderate 


3 = average 

4 = significant 

5 = essential 


Qll. Is the code designed to be reusable? 


Select the appropriate rating scale: 

II • 

f 

CHOICES Qll: 0, 1, 2, 3, 4, 5; 


0 = no influence 

1 = incidental 

2 = moderate 


3 = average 

4 = significant 

5 = essential 


Q12. Are conversion and installation included in the design? 


Select the appropriate rating scale: 

tl. 

CHOICES Q12: 0, 1, 2, 3, 4, 5; 


ASK Q13: " 

0 = no influence 

1 = incidental 

2 = moderate 


3 = average 

4 = significant 

5 = essential 


Q13. Is the system designed for multiple installations in 
different organizations? 


Select the appropriate rating scale: 

II • 

t 

CHOICES Q13: 0, 1, 2, 3, 4, 5; 


ASK Q14: " 

0 = no influence 

1 = incidental 

2 = moderate 


3 = average 

4 = significant 

5 = essential 


Q14. 


Is the application designed to facilitate change and 
ease of use by the user? 


Ill 





Select the appropriate rating scale: 

It • 

t 

CHOICES Q14: 0, 1, 2, 3, 4, 5; 


B. (ICEM2.KBS) FILE 
EXECUTE; 

RUNTIME; 

BKC0L0R=3; 

ACTIONS 

LOADFACTS fixvalue 
FIND spreadsheet; 

RULE 1 

IF retreive = YES and file = ORGANIC 

THEN DISPLAY •' 

(CALLING SPREADSHEET)" 

WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\organic 
continue = NO 
spreadsheet = found; 

RULE 2 

IF retreive = YES and file = SEMIDETACHED 

THEN DISPLAY " 

(CALLING SPREADSHEET)" 

WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\semidet 
continue = NO 
spreadsheet = found; 

RULE 3 

IF retreive = YES and file = EMBEDDED 

THEN DISPLAY" 

(CALLING SPREADSHEET)" 

WORKSHEET VPP 

WORKON c: \vpexp, c: \vpexp\einbedded 
continue = NO 
spreadsheet = found; 

RULE 4 

IF retreive = YES and file = DSSCOC 

THEN DISPLAY" 

(CALLING SPREADSHEET)" 

WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\dsscoc 
continue = NO 
spreadsheet = found; 

RULE 5 

IF retreive = YES and file = DSSFP 

THEN DISPLAY" 

(CALLING SPREADSHEET)" 

WORKSHEET VPP 
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RULE 6 
IF 

THEN 


RULE 7 
IF 

THEN 


RULE 8 
IF 

THEN 


WORKON c:\vpexp, c:\vpexp\dssfp 
continue = NO 
spreadsheet = found; 


retreive = NO and mode = ORGANIC 
DISPLAY " 


VALUES SAVED!" 

COLOR =30 
DISPLAY" 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS)-" 
WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\organic 
spreadsheet = found; 

retreive = NO and mode = SEMIDETACHED 
DISPLAY " 


VALUES SAVED!" 

COLOR =30 
DISPLAY" 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS)-" 
WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\semidet 
spreadsheet = found; 

retreive = NO and mode = EMBEDDED 
DISPLAY " 


VALUES SAVED!" 

COLOR =30 
DISPLAY" 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS)-" 
WORKSHEET VPP 
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RULE 

IF 

THEN 


RULE 

IF 

THEN 


WORKON c:\vpexp, c:\vpexp\embedded 
spreadsheet = found; 


9 

retreive = NO and model = DSSCOC 
DISPLAY " 


VALUES SAVED!" 

COLOR =30 
DISPLAY" 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS)-" 
WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\dsscoc 
spreadsheet = found; 

10 

retreive = NO and model = DSSFP 
DISPLAY " 


VALUES SAVED!" 

COLOR =30 
DISPLAY" 


(PRESS ANY KEY TO VIEW SPREADSHEET CALCULATIONS)-" 
WORKSHEET VPP 

WORKON c:\vpexp, c:\vpexp\dssfp 
spreadsheet = found; 
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